This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2] soft-fp: Add the lack of implementation for 128 bit self-contained


Zong Li <zongbox@gmail.com> 於 2018年10月16日 週二 上午12:47寫道:
>
> Joseph Myers <joseph@codesourcery.com> 於 2018年10月15日 週一 下午11:10寫道:
> >
> > On Mon, 15 Oct 2018, Zong Li wrote:
> >
> > > Here only add the lack of implementation when building the RISC-V 32-bit
> > > port.
> >
> > You're adding an implementation, not adding a lack of implementation
> > (you're adding the implementation of the pieces that are needed by the
> > RISC-V 32-bit port).  The same point applies to the proposed summary line
> > for the commit.
>
> I see, I will change that. I use 'lack' word because there are the
> implementations
> for different size in other op-*.h files, but not in op-8.h
>
> > > These marcos are used when the following situations occur at the same
> >
> > s/marcos/macros/
> >
> > > +     * soft-fp/op-8.h: Add macros for RV32 use.
> >
> > Please see the GNU Coding Standards for how to write ChangeLog entries.
> > In this case, you need to list all the new macros individually.
> >
>
> Ok, I modify it together in next version.
>
> > > +#define _FP_FRAC_CLZ_8(R, X)                    \
> >
> > A previous review comment suggested a loop here.  You expressed a
> > performance concern in
> > <https://sourceware.org/ml/libc-alpha/2018-07/msg00929.html>.  Have you
> > done any benchmarking since then to justify the concern and not making the
> > suggested change?
> >
>
> No, I didn't run some benchmarks. I worry about the performance
> because I saw the
> code generation got more one conditional branch for the looping for
> every comparisons.
> The two kinds of implementation are fine for me, but there are nobody
> to discussion that,
> so I retained the original one.

Has anyone had some suggestions? I want to ensure that we can get the
suitable implementation for glibc before I summit next version. It
seem that the looping form is more simplified and without critical
side effect, If there is no any comments, I will use the looping form
for next version.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]