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] x86-64: Compile branred.c with -mprefer-vector-width=128 [BZ #24603]


* 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.

Thanks,
Florian


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