Patchwork [x86_64,BZ,#20139] Don't allow configure with not supporting AVX512 assembler w/o --disable-avx512.

login
register
mail settings
Submitter Andrew Senkevich
Date June 27, 2016, 5:40 p.m.
Message ID <CAMXFM3tJkhW78PPe4=FUhbm=8HoOY4iouSqXxLObA0GEMTxoZA@mail.gmail.com>
Download mbox | patch
Permalink /patch/13408/
State New
Headers show

Comments

Andrew Senkevich - June 27, 2016, 5:40 p.m.
Hi,

this patch adds new configure option --enable-avx512 and defaults it for x86_64.

To fix BZ #20139 we need don't let to configure with not supporting
AVX512 assembler w/o --disable-avx512.

2016-06-27  Andrew Senkevich  <andrew.senkevich@intel.com>

        [BZ #20139]
        * configure.ac: Added --enable-avx512.
        * sysdeps/x86_64/configure.ac: Check for --disable-avx512
        if no AVX512 assembler support.
        * configure: Regenerated.
        * sysdeps/x86_64/configure: Likewise.
        * manual/install.texi (Configuring and compiling): Document
        --enable-avx512.
        * INSTALL: Regenerated.



If placing x86_64 related in root configure is not accepted please
give me an advice how to avoid it.
AC_ARG_ENABLE in sysdeps/x86_64/configure.ac doesn't work for me.


--
WBR,
Andrew
Joseph Myers - June 27, 2016, 5:53 p.m.
On Mon, 27 Jun 2016, Andrew Senkevich wrote:

> Hi,
> 
> this patch adds new configure option --enable-avx512 and defaults it for 
> x86_64.
> 
> To fix BZ #20139 we need don't let to configure with not supporting
> AVX512 assembler w/o --disable-avx512.

What assembler version is required to support AVX512, and when was that 
version released?  It might be better to increase the minimum binutils 
version for building glibc (generally, or for x86_64).
Florian Weimer - June 27, 2016, 6:03 p.m.
On 06/27/2016 07:40 PM, Andrew Senkevich wrote:
> To fix BZ #20139 we need don't let to configure with not supporting
> AVX512 assembler w/o --disable-avx512.

There is an existing configure check for HAVE_AVX512_ASM_SUPPORT.  Why 
isn't it sufficient?

Thanks,
Florian
Andrew Senkevich - June 27, 2016, 6:15 p.m.
2016-06-27 21:03 GMT+03:00 Florian Weimer <fweimer@redhat.com>:
> On 06/27/2016 07:40 PM, Andrew Senkevich wrote:
>>
>> To fix BZ #20139 we need don't let to configure with not supporting
>> AVX512 assembler w/o --disable-avx512.
>
>
> There is an existing configure check for HAVE_AVX512_ASM_SUPPORT.  Why isn't
> it sufficient?

Where are bug https://sourceware.org/bugzilla/show_bug.cgi?id=20139
It is the case when HAVE_AVX512_ASM_SUPPORT is undefined and Glibc is
built for AVX512 hardware.


--
WBR,
Andrew
Mike Frysinger - June 27, 2016, 6:16 p.m.
On 27 Jun 2016 20:40, Andrew Senkevich wrote:
> +'--disable-avx512'
> +     By default for x86_64, the GNU C Library is built with
> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
> +     doesn't support AVX512.

people shouldn't have to pass configure flags like this to get a
successful build.  we have all the info in order to figure out a
sane default.  specifying enable/disable flags is purely to not
use the default autodetection.
-mike
Florian Weimer - June 27, 2016, 6:20 p.m.
On 06/27/2016 08:15 PM, Andrew Senkevich wrote:
> 2016-06-27 21:03 GMT+03:00 Florian Weimer <fweimer@redhat.com>:
>> On 06/27/2016 07:40 PM, Andrew Senkevich wrote:
>>>
>>> To fix BZ #20139 we need don't let to configure with not supporting
>>> AVX512 assembler w/o --disable-avx512.
>>
>>
>> There is an existing configure check for HAVE_AVX512_ASM_SUPPORT.  Why isn't
>> it sufficient?
>
> Where are bug https://sourceware.org/bugzilla/show_bug.cgi?id=20139
> It is the case when HAVE_AVX512_ASM_SUPPORT is undefined and Glibc is
> built for AVX512 hardware.

It's still unclear to me what you are proposing as a remedy.

Building glibc with --disable-avx512 will still be broken, no?

Thanks,
Florian
H.J. Lu - June 27, 2016, 6:25 p.m.
On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 27 Jun 2016 20:40, Andrew Senkevich wrote:
>> +'--disable-avx512'
>> +     By default for x86_64, the GNU C Library is built with
>> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
>> +     doesn't support AVX512.
>
> people shouldn't have to pass configure flags like this to get a
> successful build.  we have all the info in order to figure out a
> sane default.  specifying enable/disable flags is purely to not
> use the default autodetection.
> -mike

We want to make sure that x86-64 glibc supports AVX512.  Any
suggestions are welcome.
H.J. Lu - June 27, 2016, 6:29 p.m.
On Mon, Jun 27, 2016 at 11:20 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/27/2016 08:15 PM, Andrew Senkevich wrote:
>>
>> 2016-06-27 21:03 GMT+03:00 Florian Weimer <fweimer@redhat.com>:
>>>
>>> On 06/27/2016 07:40 PM, Andrew Senkevich wrote:
>>>>
>>>>
>>>> To fix BZ #20139 we need don't let to configure with not supporting
>>>> AVX512 assembler w/o --disable-avx512.
>>>
>>>
>>>
>>> There is an existing configure check for HAVE_AVX512_ASM_SUPPORT.  Why
>>> isn't
>>> it sufficient?
>>
>>
>> Where are bug https://sourceware.org/bugzilla/show_bug.cgi?id=20139
>> It is the case when HAVE_AVX512_ASM_SUPPORT is undefined and Glibc is
>> built for AVX512 hardware.
>
>
> It's still unclear to me what you are proposing as a remedy.
>
> Building glibc with --disable-avx512 will still be broken, no?
>

If ld.so doesn't the first 8 save/store ZMM registers, you
may not pass parameters in ZMM registers with AVX512
kernel on AVX512 machine.   We wan to make sure that
ld.so in x86-64 glibc saves/stores ZMM registers unless
glibc is configured to disable AVX512 support.
Florian Weimer - June 27, 2016, 6:33 p.m.
On 06/27/2016 08:29 PM, H.J. Lu wrote:

> If ld.so doesn't the first 8 save/store ZMM registers, you
> may not pass parameters in ZMM registers with AVX512
> kernel on AVX512 machine.   We wan to make sure that
> ld.so in x86-64 glibc saves/stores ZMM registers unless
> glibc is configured to disable AVX512 support.

I still do not understand what is going on.

What can clobber the ZMM registers if glibc was compiled without AVX-512 
capabilities?

If ld.so support for AVX512 is a must before applications can use it, 
why has this not been built into the platform capability detection 
mechanism?

Thanks,
Florian
Andrew Senkevich - June 27, 2016, 6:36 p.m.
2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>
>> Hi,
>>
>> this patch adds new configure option --enable-avx512 and defaults it for
>> x86_64.
>>
>> To fix BZ #20139 we need don't let to configure with not supporting
>> AVX512 assembler w/o --disable-avx512.
>
> What assembler version is required to support AVX512, and when was that
> version released?  It might be better to increase the minimum binutils
> version for building glibc (generally, or for x86_64).

May be it will be the best way.  Needed version is 2.25 and it was
released at Mon, 5 Jan 2015.


--
WBR,
Andrew
H.J. Lu - June 27, 2016, 6:39 p.m.
On Mon, Jun 27, 2016 at 11:33 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/27/2016 08:29 PM, H.J. Lu wrote:
>
>> If ld.so doesn't the first 8 save/store ZMM registers, you
>> may not pass parameters in ZMM registers with AVX512
>> kernel on AVX512 machine.   We wan to make sure that
>> ld.so in x86-64 glibc saves/stores ZMM registers unless
>> glibc is configured to disable AVX512 support.
>
>
> I still do not understand what is going on.
>
> What can clobber the ZMM registers if glibc was compiled without AVX-512
> capabilities?

When AVX512 isn't supported, _dl_runtime_resolve_avx will be to used
to save the first 8 vector registers, which only saves the lower 256 bits of
vector register, for lazy binding.  When it is called on AVX512 platform,
the upper 256 bits of ZMM registers are clobbered.
Florian Weimer - June 27, 2016, 6:45 p.m.
On 06/27/2016 08:39 PM, H.J. Lu wrote:
> On Mon, Jun 27, 2016 at 11:33 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/27/2016 08:29 PM, H.J. Lu wrote:
>>
>>> If ld.so doesn't the first 8 save/store ZMM registers, you
>>> may not pass parameters in ZMM registers with AVX512
>>> kernel on AVX512 machine.   We wan to make sure that
>>> ld.so in x86-64 glibc saves/stores ZMM registers unless
>>> glibc is configured to disable AVX512 support.
>>
>>
>> I still do not understand what is going on.
>>
>> What can clobber the ZMM registers if glibc was compiled without AVX-512
>> capabilities?
>
> When AVX512 isn't supported, _dl_runtime_resolve_avx will be to used
> to save the first 8 vector registers, which only saves the lower 256 bits of
> vector register, for lazy binding.  When it is called on AVX512 platform,
> the upper 256 bits of ZMM registers are clobbered.

Thanks, I wasn't aware of the register sharing.

So this affects all existing glibc binaries, as long as they are 
compiled with AVX support.  So applications really need to detect this 
somehow before they can use AVX512 features.  Or binaries which use 
AVX512 unconditionally need to be marked in some way so that ld.so will 
refuse to load them.

Florian
Florian Weimer - June 27, 2016, 7:04 p.m.
On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>>
>>> Hi,
>>>
>>> this patch adds new configure option --enable-avx512 and defaults it for
>>> x86_64.
>>>
>>> To fix BZ #20139 we need don't let to configure with not supporting
>>> AVX512 assembler w/o --disable-avx512.
>>
>> What assembler version is required to support AVX512, and when was that
>> version released?  It might be better to increase the minimum binutils
>> version for building glibc (generally, or for x86_64).
>
> May be it will be the best way.  Needed version is 2.25 and it was
> released at Mon, 5 Jan 2015.

It's a fairly recent version.

But there has been a Debian release with it, and an Ubuntu LTS release. 
Fedora 23 (current is 24) has it, too.  We can provide it for 
downstreams of Fedora.  (Right now, Red Hat Enterprise Linux 7 is still 
suitable for glibc development on x86_64, but is at some 2.23-derived 
release, and a requirement for 2.25 would put an end to this.)

I'm not familiar with the openSUSE/SLES branching model.  openSUSE Leap 
42.1 has 2.25, and is marked as “official release”.  There seem to be 
2.25 binutils built for SLE-12, but I think you have to use them already 
to replace the 2.19-derived binutils in stock SLE-12.

But even if we force the use of AVX512 for future glibc releases, it 
will not stop applications from misbehaving in weird ways when they run 
on older glibc versions.  This is my main worry.

Thanks,
Florian
Mike Frysinger - June 27, 2016, 7:04 p.m.
On 27 Jun 2016 11:25, H.J. Lu wrote:
> On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 27 Jun 2016 20:40, Andrew Senkevich wrote:
> >> +'--disable-avx512'
> >> +     By default for x86_64, the GNU C Library is built with
> >> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
> >> +     doesn't support AVX512.
> >
> > people shouldn't have to pass configure flags like this to get a
> > successful build.  we have all the info in order to figure out a
> > sane default.  specifying enable/disable flags is purely to not
> > use the default autodetection.
> 
> We want to make sure that x86-64 glibc supports AVX512.  Any
> suggestions are welcome.

i don't see how that's relevant to what i said.  if the assembler can
be probed to see if it supports AVX512, then do that.  why do you need
a configure flag at all in that case ?
-mike
H.J. Lu - June 27, 2016, 7:07 p.m.
On Mon, Jun 27, 2016 at 12:04 PM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
>>
>> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>>>
>>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>>>
>>>> Hi,
>>>>
>>>> this patch adds new configure option --enable-avx512 and defaults it for
>>>> x86_64.
>>>>
>>>> To fix BZ #20139 we need don't let to configure with not supporting
>>>> AVX512 assembler w/o --disable-avx512.
>>>
>>>
>>> What assembler version is required to support AVX512, and when was that
>>> version released?  It might be better to increase the minimum binutils
>>> version for building glibc (generally, or for x86_64).
>>
>>
>> May be it will be the best way.  Needed version is 2.25 and it was
>> released at Mon, 5 Jan 2015.
>
>
> It's a fairly recent version.
>

Binutils 2.24 released in Dec., 2013 supports AVX512.
H.J. Lu - June 27, 2016, 7:09 p.m.
On Mon, Jun 27, 2016 at 12:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 27 Jun 2016 11:25, H.J. Lu wrote:
>> On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> > On 27 Jun 2016 20:40, Andrew Senkevich wrote:
>> >> +'--disable-avx512'
>> >> +     By default for x86_64, the GNU C Library is built with
>> >> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
>> >> +     doesn't support AVX512.
>> >
>> > people shouldn't have to pass configure flags like this to get a
>> > successful build.  we have all the info in order to figure out a
>> > sane default.  specifying enable/disable flags is purely to not
>> > use the default autodetection.
>>
>> We want to make sure that x86-64 glibc supports AVX512.  Any
>> suggestions are welcome.
>
> i don't see how that's relevant to what i said.  if the assembler can
> be probed to see if it supports AVX512, then do that.  why do you need
> a configure flag at all in that case ?
> -mike

We want to REQUIRE AVX512 support for x86-64 glibc build.
Mike Frysinger - June 27, 2016, 7:17 p.m.
On 27 Jun 2016 12:09, H.J. Lu wrote:
> On Mon, Jun 27, 2016 at 12:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On 27 Jun 2016 11:25, H.J. Lu wrote:
> >> On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> >> > On 27 Jun 2016 20:40, Andrew Senkevich wrote:
> >> >> +'--disable-avx512'
> >> >> +     By default for x86_64, the GNU C Library is built with
> >> >> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
> >> >> +     doesn't support AVX512.
> >> >
> >> > people shouldn't have to pass configure flags like this to get a
> >> > successful build.  we have all the info in order to figure out a
> >> > sane default.  specifying enable/disable flags is purely to not
> >> > use the default autodetection.
> >>
> >> We want to make sure that x86-64 glibc supports AVX512.  Any
> >> suggestions are welcome.
> >
> > i don't see how that's relevant to what i said.  if the assembler can
> > be probed to see if it supports AVX512, then do that.  why do you need
> > a configure flag at all in that case ?
> 
> We want to REQUIRE AVX512 support for x86-64 glibc build.

then why are you adding a configure flag ?  why is AVX512 special
compared to any other ISA feature ?  if the majority of people are
getting their builds from distros, is a flag really needed ?

let's assume that you really really want the flag.  my point still
stands: the default should *not* be fatal *regardless* of what the
assembler supports.  the only time you may throw an error is if the
user explicitly passed --enable-avx512.  the --disable flag is just
a convenience for the cache var, and the default is to use the test
of the assembler to determine whether to enable it in glibc.
-mike
H.J. Lu - June 27, 2016, 7:40 p.m.
On Mon, Jun 27, 2016 at 12:17 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 27 Jun 2016 12:09, H.J. Lu wrote:
>> On Mon, Jun 27, 2016 at 12:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> > On 27 Jun 2016 11:25, H.J. Lu wrote:
>> >> On Mon, Jun 27, 2016 at 11:16 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> >> > On 27 Jun 2016 20:40, Andrew Senkevich wrote:
>> >> >> +'--disable-avx512'
>> >> >> +     By default for x86_64, the GNU C Library is built with
>> >> >> +     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
>> >> >> +     doesn't support AVX512.
>> >> >
>> >> > people shouldn't have to pass configure flags like this to get a
>> >> > successful build.  we have all the info in order to figure out a
>> >> > sane default.  specifying enable/disable flags is purely to not
>> >> > use the default autodetection.
>> >>
>> >> We want to make sure that x86-64 glibc supports AVX512.  Any
>> >> suggestions are welcome.
>> >
>> > i don't see how that's relevant to what i said.  if the assembler can
>> > be probed to see if it supports AVX512, then do that.  why do you need
>> > a configure flag at all in that case ?
>>
>> We want to REQUIRE AVX512 support for x86-64 glibc build.
>
> then why are you adding a configure flag ?  why is AVX512 special
> compared to any other ISA feature ?  if the majority of people are
> getting their builds from distros, is a flag really needed ?

See

https://sourceware.org/ml/libc-alpha/2016-06/msg01061.html
Joseph Myers - June 27, 2016, 8:22 p.m.
On Mon, 27 Jun 2016, H.J. Lu wrote:

> >> May be it will be the best way.  Needed version is 2.25 and it was
> >> released at Mon, 5 Jan 2015.
> >
> >
> > It's a fairly recent version.
> >
> 
> Binutils 2.24 released in Dec., 2013 supports AVX512.

Time-based updates to the binutils requirements would indicate moving to 
requiring binutils 2.24 for building glibc 2.25 and later rather than 
requiring it now for building glibc 2.24, but given a clear reason for the 
requirement I wouldn't object to bringing it forward.

Note: if we require a version with AVX512 support, we should also remove 
all the configure / preprocessor / makefile conditionals on such support, 
and all places where .byte directives are used for instruction encoding 
because of instructions not supported in older versions.
Florian Weimer - June 27, 2016, 8:44 p.m.
On 06/27/2016 10:22 PM, Joseph Myers wrote:
> On Mon, 27 Jun 2016, H.J. Lu wrote:
>
>>>> May be it will be the best way.  Needed version is 2.25 and it was
>>>> released at Mon, 5 Jan 2015.
>>>
>>>
>>> It's a fairly recent version.
>>>
>>
>> Binutils 2.24 released in Dec., 2013 supports AVX512.
>
> Time-based updates to the binutils requirements would indicate moving to
> requiring binutils 2.24 for building glibc 2.25 and later rather than
> requiring it now for building glibc 2.24, but given a clear reason for the
> requirement I wouldn't object to bringing it forward.
>
> Note: if we require a version with AVX512 support, we should also remove
> all the configure / preprocessor / makefile conditionals on such support,
> and all places where .byte directives are used for instruction encoding
> because of instructions not supported in older versions.

Alternatively, we could upstream the .byte-based AVX512 hacks we have 
for supporting older binutils in our downstream glibc builds for Red Hat 
Enterprise Linux.  But just requiring the newer glibc version is 
certainly the cleaner approach.

Thanks,
Florian
H.J. Lu - June 27, 2016, 8:59 p.m.
On Mon, Jun 27, 2016 at 1:49 PM, Andrew Senkevich
<andrew.n.senkevich@gmail.com> wrote:
> 27 Июн 2016 г. 22:07 пользователь "H.J. Lu" <hjl.tools@gmail.com> написал:
>>
>> On Mon, Jun 27, 2016 at 12:04 PM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>> > On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
>> >>
>> >> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>> >>>
>> >>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> this patch adds new configure option --enable-avx512 and defaults it
>> >>>> for
>> >>>> x86_64.
>> >>>>
>> >>>> To fix BZ #20139 we need don't let to configure with not supporting
>> >>>> AVX512 assembler w/o --disable-avx512.
>> >>>
>> >>>
>> >>> What assembler version is required to support AVX512, and when was
>> >>> that
>> >>> version released?  It might be better to increase the minimum binutils
>> >>> version for building glibc (generally, or for x86_64).
>> >>
>> >>
>> >> May be it will be the best way.  Needed version is 2.25 and it was
>> >> released at Mon, 5 Jan 2015.
>> >
>> >
>> > It's a fairly recent version.
>> >
>>
>> Binutils 2.24 released in Dec., 2013 supports AVX512.
>
> Yes, but not all required.  There were some with ZMM registers supported
> from 2.25.  According configure check defining HAVE_AVX512_ASM_SUPPORT was
> changed for that reason.

Will binutils 2.24 able to save/restore ZMM registers?
Andrew Senkevich - June 27, 2016, 9:01 p.m.
2016-06-27 22:07 GMT+03:00, H.J. Lu <hjl.tools@gmail.com>:
> On Mon, Jun 27, 2016 at 12:04 PM, Florian Weimer <fweimer@redhat.com>
> wrote:
>> On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
>>>
>>> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>>>>
>>>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> this patch adds new configure option --enable-avx512 and defaults it
>>>>> for
>>>>> x86_64.
>>>>>
>>>>> To fix BZ #20139 we need don't let to configure with not supporting
>>>>> AVX512 assembler w/o --disable-avx512.
>>>>
>>>>
>>>> What assembler version is required to support AVX512, and when was that
>>>> version released?  It might be better to increase the minimum binutils
>>>> version for building glibc (generally, or for x86_64).
>>>
>>>
>>> May be it will be the best way.  Needed version is 2.25 and it was
>>> released at Mon, 5 Jan 2015.
>>
>>
>> It's a fairly recent version.
>>
>
> Binutils 2.24 released in Dec., 2013 supports AVX512.

Yes, but not all required.  There were some with ZMM registers supported
from 2.25.  According configure check defining HAVE_AVX512_ASM_SUPPORT was
changed for that reason.


--
WBR,
Andrew
Andreas Schwab - June 27, 2016, 9:50 p.m.
Florian Weimer <fweimer@redhat.com> writes:

> I'm not familiar with the openSUSE/SLES branching model.  openSUSE Leap
> 42.1 has 2.25, and is marked as “official release”.  There seem to be 2.25
> binutils built for SLE-12, but I think you have to use them already to
> replace the 2.19-derived binutils in stock SLE-12.

I think you confused that with SLE-11.  SLE-12 and even SLE-11-SP4
already have 2.24.

Andreas.
H.J. Lu - June 27, 2016, 10:46 p.m.
On Mon, Jun 27, 2016 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jun 27, 2016 at 1:49 PM, Andrew Senkevich
> <andrew.n.senkevich@gmail.com> wrote:
>> 27 Июн 2016 г. 22:07 пользователь "H.J. Lu" <hjl.tools@gmail.com> написал:
>>>
>>> On Mon, Jun 27, 2016 at 12:04 PM, Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>> > On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
>>> >>
>>> >> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>>> >>>
>>> >>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> this patch adds new configure option --enable-avx512 and defaults it
>>> >>>> for
>>> >>>> x86_64.
>>> >>>>
>>> >>>> To fix BZ #20139 we need don't let to configure with not supporting
>>> >>>> AVX512 assembler w/o --disable-avx512.
>>> >>>
>>> >>>
>>> >>> What assembler version is required to support AVX512, and when was
>>> >>> that
>>> >>> version released?  It might be better to increase the minimum binutils
>>> >>> version for building glibc (generally, or for x86_64).
>>> >>
>>> >>
>>> >> May be it will be the best way.  Needed version is 2.25 and it was
>>> >> released at Mon, 5 Jan 2015.
>>> >
>>> >
>>> > It's a fairly recent version.
>>> >
>>>
>>> Binutils 2.24 released in Dec., 2013 supports AVX512.
>>
>> Yes, but not all required.  There were some with ZMM registers supported
>> from 2.25.  According configure check defining HAVE_AVX512_ASM_SUPPORT was
>> changed for that reason.
>
> Will binutils 2.24 able to save/restore ZMM registers?
>

The additional check is for SVML.  We can require binutils 2.24
for x86-64 glibc and use HAVE_AVX512_ASM_SUPPORT only
for SVML.
Florian Weimer - June 28, 2016, 6:26 a.m.
On 06/27/2016 11:50 PM, Andreas Schwab wrote:
> Florian Weimer <fweimer@redhat.com> writes:
>
>> I'm not familiar with the openSUSE/SLES branching model.  openSUSE Leap
>> 42.1 has 2.25, and is marked as “official release”.  There seem to be 2.25
>> binutils built for SLE-12, but I think you have to use them already to
>> replace the 2.19-derived binutils in stock SLE-12.
>
> I think you confused that with SLE-11.

Quite likely.

> SLE-12 and even SLE-11-SP4
> already have 2.24.

Thanks for providing this background information.

Florian
Florian Weimer - June 28, 2016, 11:46 a.m.
On 06/27/2016 07:40 PM, Andrew Senkevich wrote:
> Hi,
>
> this patch adds new configure option --enable-avx512 and defaults it for x86_64.
>
> To fix BZ #20139 we need don't let to configure with not supporting
> AVX512 assembler w/o --disable-avx512.
>
> 2016-06-27  Andrew Senkevich  <andrew.senkevich@intel.com>
>
>         [BZ #20139]
>         * configure.ac: Added --enable-avx512.
>         * sysdeps/x86_64/configure.ac: Check for --disable-avx512
>         if no AVX512 assembler support.
>         * configure: Regenerated.
>         * sysdeps/x86_64/configure: Likewise.
>         * manual/install.texi (Configuring and compiling): Document
>         --enable-avx512.
>         * INSTALL: Regenerated.

I thought about this some more, and we have to either of two things:

(a) Tell the kernel to set the feature support mask using XSETBV to the 
AND of what is supported by the hardware, the kernel, and the dynamic 
linker.  This likely needs kernel changes (new prctl interface).

or

(b) Use XSAVE/XRSTOR to save and restore the extended CPU state around 
the call to _dl_fixup, instead of guessing what the kernel and 
application code expects.

If we don't anything here, we will keep running into the same issue, 
which is not acceptable IMHO.


Option (b) seems to be rather costly both in terms of stack space (2688 
bytes) and cycles.  So we would probably keep the existing wrappers 
which save registers selectively, and use approach (b) only in case when 
XGETBV with ECX=0 returns feature bits we know nothing about (or cannot 
build support into glibc, as with !HAVE_AVX512_ASM_SUPPORT).

Comments?

Thanks,
Florian
Andrew Senkevich - June 28, 2016, 12:45 p.m.
2016-06-27 23:59 GMT+03:00 H.J. Lu <hjl.tools@gmail.com>:
> On Mon, Jun 27, 2016 at 1:49 PM, Andrew Senkevich
> <andrew.n.senkevich@gmail.com> wrote:
>> 27 Июн 2016 г. 22:07 пользователь "H.J. Lu" <hjl.tools@gmail.com> написал:
>>>
>>> On Mon, Jun 27, 2016 at 12:04 PM, Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>> > On 06/27/2016 08:36 PM, Andrew Senkevich wrote:
>>> >>
>>> >> 2016-06-27 20:53 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
>>> >>>
>>> >>> On Mon, 27 Jun 2016, Andrew Senkevich wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> this patch adds new configure option --enable-avx512 and defaults it
>>> >>>> for
>>> >>>> x86_64.
>>> >>>>
>>> >>>> To fix BZ #20139 we need don't let to configure with not supporting
>>> >>>> AVX512 assembler w/o --disable-avx512.
>>> >>>
>>> >>>
>>> >>> What assembler version is required to support AVX512, and when was
>>> >>> that
>>> >>> version released?  It might be better to increase the minimum binutils
>>> >>> version for building glibc (generally, or for x86_64).
>>> >>
>>> >>
>>> >> May be it will be the best way.  Needed version is 2.25 and it was
>>> >> released at Mon, 5 Jan 2015.
>>> >
>>> >
>>> > It's a fairly recent version.
>>> >
>>>
>>> Binutils 2.24 released in Dec., 2013 supports AVX512.
>>
>> Yes, but not all required.  There were some with ZMM registers supported
>> from 2.25.  According configure check defining HAVE_AVX512_ASM_SUPPORT was
>> changed for that reason.
>
> Will binutils 2.24 able to save/restore ZMM registers?

Yes, binutils 2.24 is enough for that.


--
WBR,
Andrew
Andrew Senkevich - June 28, 2016, 1:04 p.m.
2016-06-27 23:22 GMT+03:00 Joseph Myers <joseph@codesourcery.com>:
> On Mon, 27 Jun 2016, H.J. Lu wrote:
>
>> >> May be it will be the best way.  Needed version is 2.25 and it was
>> >> released at Mon, 5 Jan 2015.
>> >
>> >
>> > It's a fairly recent version.
>> >
>>
>> Binutils 2.24 released in Dec., 2013 supports AVX512.
>
> Time-based updates to the binutils requirements would indicate moving to
> requiring binutils 2.24 for building glibc 2.25 and later rather than
> requiring it now for building glibc 2.24, but given a clear reason for the
> requirement I wouldn't object to bringing it forward.
>
> Note: if we require a version with AVX512 support, we should also remove
> all the configure / preprocessor / makefile conditionals on such support,
> and all places where .byte directives are used for instruction encoding
> because of instructions not supported in older versions.

If current issue is enough reason for requiring binutils 2.24 now for
building Glibc 2.24 I can prepare this patch.

In existing Glibc release it should be fixed with .byte-based encodings I think.


--
WBR,
Andrew

Patch

diff --git a/INSTALL b/INSTALL
index ec3445f..505c032 100644
--- a/INSTALL
+++ b/INSTALL
@@ -158,6 +158,11 @@  will be used, and CFLAGS sets optimization
options for the compiler.
      By default for x86_64, the GNU C Library is built with vector math
      library.  Use this option to disable vector math library.

+'--disable-avx512'
+     By default for x86_64, the GNU C Library is built with
+     '--enable-avx512'.  Configure with '--disable-avx512' if assembler
+     doesn't support AVX512.
+
 '--build=BUILD-SYSTEM'
 '--host=HOST-SYSTEM'
      These options are for cross-compiling.  If you specify both options
diff --git a/configure b/configure
index 19a4829..727f57c 100755
--- a/configure
+++ b/configure
@@ -774,6 +774,7 @@  enable_build_nscd
 enable_nscd
 enable_pt_chown
 enable_mathvec
+enable_avx512
 with_cpu
 '
       ac_precious_vars='build_alias
@@ -1442,6 +1443,8 @@  Optional Features:
   --enable-pt_chown       Enable building and installing pt_chown
   --enable-mathvec        Enable building and installing mathvec [default
                           depends on architecture]
+  --enable-avx512         Enable AVX512 assembler support [default depends on
+                          architecture]

 Optional Packages:
   --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
@@ -3666,6 +3669,14 @@  else
 fi


+# Check whether --enable-avx512 was given.
+if test "${enable_avx512+set}" = set; then :
+  enableval=$enable_avx512; avx512=$enableval
+else
+  avx512=notset
+fi
+
+
 # We keep the original values in `$config_*' and never modify them, so we
 # can write them unchanged into config.make.  Everything else uses
 # $machine, $vendor, and $os, and changes them whenever convenient.
diff --git a/configure.ac b/configure.ac
index 123f0d2..c983a54 100644
--- a/configure.ac
+++ b/configure.ac
@@ -413,6 +413,12 @@  AC_ARG_ENABLE([mathvec],
              [build_mathvec=$enableval],
              [build_mathvec=notset])

+AC_ARG_ENABLE([avx512],
+             [AS_HELP_STRING([--enable-avx512],
+             [Enable AVX512 assembler support @<:@default depends on
architecture@:>@])],
+             [avx512=$enableval],
+             [avx512=notset])
+
 # We keep the original values in `$config_*' and never modify them, so we
 # can write them unchanged into config.make.  Everything else uses
 # $machine, $vendor, and $os, and changes them whenever convenient.
diff --git a/manual/install.texi b/manual/install.texi
index 79ee45f..3dcdf88 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -189,6 +189,10 @@  configure with @option{--disable-werror}.
 By default for x86_64, @theglibc{} is built with vector math library.
 Use this option to disable vector math library.

+@item --disable-avx512
+By default for x86_64, @theglibc{} is built with @option{--enable-avx512}.
+Configure with @option{--disable-avx512} if assembler doesn't support AVX512.
+
 @item --build=@var{build-system}
 @itemx --host=@var{host-system}
 These options are for cross-compiling.  If you specify both options and
diff --git a/sysdeps/x86_64/configure b/sysdeps/x86_64/configure
index 88fbfe4..4cc8d52 100644
--- a/sysdeps/x86_64/configure
+++ b/sysdeps/x86_64/configure
@@ -24,9 +24,18 @@  rm -f conftest*
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_asm_avx512" >&5
 $as_echo "$libc_cv_asm_avx512" >&6; }
+
+if test x"$avx512" = xnotset; then
+  avx512=yes
+fi
+
 if test $libc_cv_asm_avx512 = yes; then
   $as_echo "#define HAVE_AVX512_ASM_SUPPORT 1" >>confdefs.h

+else
+  if test x"$avx512" = xyes; then
+    as_fn_error $? "assembler does not support AVX512 but default is
--enable-avx512" "$LINENO" 5
+  fi
 fi

 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for AVX512 support" >&5
diff --git a/sysdeps/x86_64/configure.ac b/sysdeps/x86_64/configure.ac
index b39309e..5f1ad43 100644
--- a/sysdeps/x86_64/configure.ac
+++ b/sysdeps/x86_64/configure.ac
@@ -13,8 +13,17 @@  else
   libc_cv_asm_avx512=no
 fi
 rm -f conftest*])
+
+if test x"$avx512" = xnotset; then
+  avx512=yes
+fi
+
 if test $libc_cv_asm_avx512 = yes; then
   AC_DEFINE(HAVE_AVX512_ASM_SUPPORT)
+else
+  if test x"$avx512" = xyes; then
+    AC_MSG_ERROR([assembler does not support AVX512 but default is
--enable-avx512])
+  fi
 fi

 dnl Check if -mavx512f works.