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

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
-O3 with AVX vectorizes some loops in sysdeps/ieee754/dbl-64/branred.c
with 256-bit vector instructions, which leads to store forward stall:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579

There is no easy fix in compiler.  This patch limits vector width to
128 bits to work around this issue.  It improves performance of sin
and cos by more than 40% on Skylake compiled with -O3 -march=skylake.

OK for master branch?

* sysdeps/x86_64/fpu/Makefile (CFLAGS-branred.c): New.  Set
to -mprefer-vector-width=128.

--
H.J.

0001-x86-64-Compile-branred.c-with-mprefer-vector-width-1.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* H. J. Lu:

> -O3 with AVX vectorizes some loops in sysdeps/ieee754/dbl-64/branred.c
> with 256-bit vector instructions, which leads to store forward stall:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
>
> There is no easy fix in compiler.  This patch limits vector width to
> 128 bits to work around this issue.  It improves performance of sin
> and cos by more than 40% on Skylake compiled with -O3 -march=skylake.
>
> OK for master branch?
>
> * sysdeps/x86_64/fpu/Makefile (CFLAGS-branred.c): New.  Set
> to -mprefer-vector-width=128.

This is bug 24603, right?

Let's hope that the reproducer in the test case is misleadingly reduced,
and we can fix the actual issue in the compiler.  I updated the GCC PR.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Fri, Jun 7, 2019 at 11:53 AM Florian Weimer <[hidden email]> wrote:

>
> * H. J. Lu:
>
> > -O3 with AVX vectorizes some loops in sysdeps/ieee754/dbl-64/branred.c
> > with 256-bit vector instructions, which leads to store forward stall:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
> >
> > There is no easy fix in compiler.  This patch limits vector width to
> > 128 bits to work around this issue.  It improves performance of sin
> > and cos by more than 40% on Skylake compiled with -O3 -march=skylake.
> >
> > OK for master branch?
> >
> > * sysdeps/x86_64/fpu/Makefile (CFLAGS-branred.c): New.  Set
> > to -mprefer-vector-width=128.
>
> This is bug 24603, right?

Yes.

> Let's hope that the reproducer in the test case is misleadingly reduced,
> and we can fix the actual issue in the compiler.  I updated the GCC PR.
>

It makes when arrays are 32-byte aligned.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
In reply to this post by H.J. Lu-30
On Fri, 7 Jun 2019, H.J. Lu wrote:

> -O3 with AVX vectorizes some loops in sysdeps/ieee754/dbl-64/branred.c
> with 256-bit vector instructions, which leads to store forward stall:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
>
> There is no easy fix in compiler.  This patch limits vector width to
> 128 bits to work around this issue.  It improves performance of sin
> and cos by more than 40% on Skylake compiled with -O3 -march=skylake.
>
> OK for master branch?
>
> * sysdeps/x86_64/fpu/Makefile (CFLAGS-branred.c): New.  Set
> to -mprefer-vector-width=128.

This is a case where the Makefile definition clearly needs a comment
explaining the issue, stating what GCC version is known to have the issue
and pointing to the GCC bug.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Mon, Jun 10, 2019 at 8:45 AM Joseph Myers <[hidden email]> wrote:

>
> On Fri, 7 Jun 2019, H.J. Lu wrote:
>
> > -O3 with AVX vectorizes some loops in sysdeps/ieee754/dbl-64/branred.c
> > with 256-bit vector instructions, which leads to store forward stall:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
> >
> > There is no easy fix in compiler.  This patch limits vector width to
> > 128 bits to work around this issue.  It improves performance of sin
> > and cos by more than 40% on Skylake compiled with -O3 -march=skylake.
> >
> > OK for master branch?
> >
> > * sysdeps/x86_64/fpu/Makefile (CFLAGS-branred.c): New.  Set
> > to -mprefer-vector-width=128.
>
> This is a case where the Makefile definition clearly needs a comment
> explaining the issue, stating what GCC version is known to have the issue
> and pointing to the GCC bug.
>
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?

Thanks.

--
H.J.

0001-x86-64-Compile-branred.c-with-mprefer-vector-width-1.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* 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?

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:

>
> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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

--
H.J.
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* H. J. Lu:

> On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:
>>
>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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).

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Tue, Jun 11, 2019 at 9:16 AM Florian Weimer <[hidden email]> wrote:

>
> * H. J. Lu:
>
> > On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:
> >>
> >> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Adhemerval Zanella-2
In reply to this post by Florian Weimer-5


On 11/06/2019 13:16, Florian Weimer wrote:

> * H. J. Lu:
>
>> On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:
>>>
>>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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).
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
In reply to this post by Florian Weimer-5
* Florian Weimer:

> * H. J. Lu:
>
>> On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:
>>>
>>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Fri, Jun 14, 2019 at 6:58 AM Florian Weimer <[hidden email]> wrote:

>
> * Florian Weimer:
>
> > * H. J. Lu:
> >
> >> On Tue, Jun 11, 2019 at 9:07 AM H.J. Lu <[hidden email]> wrote:
> >>>
> >>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Jeff Law
In reply to this post by Florian Weimer-5
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 <[hidden email]> wrote:
>>>>
>>>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
On Fri, Jun 14, 2019 at 9:43 AM Jeff Law <[hidden email]> wrote:

>
> 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 <[hidden email]> wrote:
> >>>>
> >>>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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.
>
We know GCC 8 and 9 have this issue.  But we don't know when this issue
will be fixed in GCC and we should allow building glibc with GCC newer than
the current minimum version, including GCC 10.  How should GCC version
be checked here?

--
H.J.
Reply | Threaded
Open this post in threaded view
|

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

Jeff Law
On 6/17/19 1:06 PM, H.J. Lu wrote:

> On Fri, Jun 14, 2019 at 9:43 AM Jeff Law <[hidden email]> wrote:
>>
>> 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 <[hidden email]> wrote:
>>>>>>
>>>>>> On Tue, Jun 11, 2019 at 9:02 AM Florian Weimer <[hidden email]> 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.
>>
> We know GCC 8 and 9 have this issue.  But we don't know when this issue
> will be fixed in GCC and we should allow building glibc with GCC newer than
> the current minimum version, including GCC 10.  How should GCC version
> be checked here?
ISTM that 8, 9, 10 would use the new flag.  11 would issue an error
which would trigger a reinvestigation roughly a year from now.

The glibc maintainers would have the final say about this -- it's just
an idea off the top of my head.

jeff
>

Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
* Jeff Law:

> ISTM that 8, 9, 10 would use the new flag.  11 would issue an error
> which would trigger a reinvestigation roughly a year from now.

Do you suggest to put in a #warning for GCC 11, so that people can
configure with --disable-werror and still build with GCC 11?

Given that GCC 11 will probably add other warnings that break the build,
this proposal isn't entirely unreasonable (even though I generally
dislike such time bombs).

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
On Mon, 17 Jun 2019, Florian Weimer wrote:

> * Jeff Law:
>
> > ISTM that 8, 9, 10 would use the new flag.  11 would issue an error
> > which would trigger a reinvestigation roughly a year from now.
>
> Do you suggest to put in a #warning for GCC 11, so that people can
> configure with --disable-werror and still build with GCC 11?

I don't think that's a good idea.  We might want e.g. a helper script to
find places in the source tree to revisit after some given GCC version is
out / after some given GCC version is no longer supported for building
glibc.  (E.g. DIAG_IGNORE_NEEDS_COMMENT calls where the version specified
is now too old to build glibc and so we should see if the warning in
question still appears with the oldest supported version.)  That implies
having a limited number of standard ways to mark such places in the
sources so they can be found later.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

H.J. Lu-30
In reply to this post by Florian Weimer-5
On Mon, Jun 17, 2019 at 12:12 PM Florian Weimer <[hidden email]> wrote:

>
> * Jeff Law:
>
> > ISTM that 8, 9, 10 would use the new flag.  11 would issue an error
> > which would trigger a reinvestigation roughly a year from now.
>
> Do you suggest to put in a #warning for GCC 11, so that people can
> configure with --disable-werror and still build with GCC 11?
>
> Given that GCC 11 will probably add other warnings that break the build,
> this proposal isn't entirely unreasonable (even though I generally
> dislike such time bombs).
>

Since there is no issue in source, this requires an artificial warning
purely based on GCC version.   We can place GCC version check in
configure script with explicit -mprefer-vector-width=128 support.

--enable-mprefer-vector-width:

1.  Default.  For GCC 8, 9, 10, use -mprefer-vector-width=128.
For GCC 11 and above, issue a configure error.
2.  Enabled.  No GCC version check, use -mprefer-vector-width=128.
3.  Disabled.  No GCC version check, don't use -mprefer-vector-width=128.

--
H.J.
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
On Mon, 17 Jun 2019, H.J. Lu wrote:

> On Mon, Jun 17, 2019 at 12:12 PM Florian Weimer <[hidden email]> wrote:
> >
> > * Jeff Law:
> >
> > > ISTM that 8, 9, 10 would use the new flag.  11 would issue an error
> > > which would trigger a reinvestigation roughly a year from now.
> >
> > Do you suggest to put in a #warning for GCC 11, so that people can
> > configure with --disable-werror and still build with GCC 11?
> >
> > Given that GCC 11 will probably add other warnings that break the build,
> > this proposal isn't entirely unreasonable (even though I generally
> > dislike such time bombs).
> >
>
> Since there is no issue in source, this requires an artificial warning
> purely based on GCC version.   We can place GCC version check in
> configure script with explicit -mprefer-vector-width=128 support.
>
> --enable-mprefer-vector-width:
>
> 1.  Default.  For GCC 8, 9, 10, use -mprefer-vector-width=128.
> For GCC 11 and above, issue a configure error.

I don't think anything causing the build to break with newer GCC versions
is appropriate.

--
Joseph S. Myers
[hidden email]
12