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 11/06/2019 13:16, Florian Weimer 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 fact I have been playing in make powerpc sysdeps less convoluted and
I almost sure this snippet could be removed without performance differences,
as for some mpa.c hacks that tried to overcome some compiler not being
able to optimize that eventually turned out to produce worse results in
newer version and chips (c4c0848bbb7a4ad6ab8149abf982a0f10fd2821b).