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

  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
  

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

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
  

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
  

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
  

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
  

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.
  

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.
  

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
  

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
  

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.
  

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
  

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
  

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
  

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.
  

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.
  

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
  

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
  

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.
  

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
  

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?
  

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
  

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.
  

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.
  

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
  

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
  

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
  

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