Message ID | CAMXFM3tJkhW78PPe4=FUhbm=8HoOY4iouSqXxLObA0GEMTxoZA@mail.gmail.com |
---|---|
State | New |
Headers | show |
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
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.