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

[Jeff Law <law at redhat dot com>]

On 6/14/19 7:58 AM, Florian Weimer 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.
So one way to address this would be to somehow conditionalize the bits
on the GCC version where they were an issue.  If the version number is
higher then issue an error of some kind which would force someone to
look at the problem again.

But I certainly understand the concern here :-)

jeff