This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Compile branred.c with -mprefer-vector-width=128 [BZ #24603]
On Tue, Jun 11, 2019 at 9:16 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <fweimer@redhat.com> wrote:
> >> >
> >> > * H. J. Lu:
> >> >
> >> > > Fixed. I also added check for -mprefer-vector-width=128 which is new in GCC 8.
> >> > > GCC 7 doesn't have this problem since it doesn't vectorize the second loop.
> >> > >
> >> > > Here is the updated patch.
> >> > >
> >> > > OK for master?
> >> >
> >> > I still don't understand why we need a workaround for a GCC performance
> >> > bug in glibc. Is there any precedent for this?
> >> >
> >>
> >> I don't know if we ever investigated performance impacts of different GCC
> >> optimizations on glibc.
> >>
> >
> > I found:
> >
> > sysdeps/powerpc/powerpc64/power4/Makefile:CFLAGS-memmove.c += --param
> > max-variable-expansions-in-unroller=2 --param max-unroll-times=2
> > -funroll-loops -fpeel-loops
>
> That's been there since before 2012. This reflects my main concern
> about such tweaks: That they will never be reviewed and removed when
> they are no longer necessary (and probably have negative impact).
>
In the case of sysdeps/ieee754/dbl-64/branred.c, 128-bit vector
instructions give better performance that 256-bit . It won't change
with different or new compilers.
--
H.J.