Re: [PATCH] x86-64: Compile branred.c with -mprefer-vector-width=128 [BZ #24603]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jun 14, 2019 at 6:58 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Florian Weimer:
>
> > * 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).
>
> For the record, this is not a strong objection to your patch, H.J.
>

In this particular case, 256-bit vectorizer caused 40% slowdown in
sin/cos bench.
After the GCC bug is fixed, we should update it to check for the fixed GCC.

I'd like to have a resolution before glibc 2.31 is released.

Thanks.

-- 
H.J.