buildtools/binutils-avx512-check.sh

buildtools/binutils-avx512-check.sh

[Dmitry Kozlyuk]

Hello,

I'm working on improvement of Linux-to-Windows cross-compilation using MinGW.
Currently there is c_args = '-mno-avx512f' in config/x86/cross-mingw, however,
1) baseline meson 0.49.2 doesn't like it*
2) it should be in machine_args because they are checked in various places
3) I don't like disabling AVX512F if there is really no issue**
So I started looking at the subject script.

* '-mno-avx512f' should be ['-mno-avx512f'], but then the build of lib/net
  breaks, because meson 0.49.2 and 0.57.0 (native Windows baseline)
  order compiler arguments differently.

** There was a .seh_savemm bug with MinGW that -mno-avx512f was trying to fix,
   but I believe that -fno-asynchronous-unwind tables was the final solution.
   However, AVX512 support is still broken for native MinGW builds, see below.

First question. In config/x86/meson.build we have:

# get binutils version for the workaround of Bug 97
if not is_windows
    binutils_ok = run_command(binutils_avx512_check)
    if binutils_ok.returncode() != 0 and cc.has_argument('-mno-avx512f')
        machine_args += '-mno-avx512f'
        warning('Binutils error with AVX512 assembly, disabling AVX512
support')
    endif
endif

This is a GNU binutils bug and if I understand correctly,
it doesn't affect builds that use LLVM binutils (FreeBSD and Windows+clang).
The script also uses ${AS:-as} and objdump, that may be missing.
Consequently, AVX512F may be disabled for LLVM-based builds
because GNU toolchain has a bug or is just absent:

root@freebsd:/tmp/dpdk # meson build
[...]
config/x86/meson.build:9: WARNING: Binutils error with AVX512 assembly,
disabling AVX512 support
[...]

root@freebsd:/tmp/dpdk # uname -r
13.0-RELEASE

root@freebsd:/tmp/dpdk # ./buildtools/binutils-avx512-check.sh
./buildtools/binutils-avx512-check.sh: as: not found
./buildtools/binutils-avx512-check.sh: objdump: not found
vpgatherqq displacement error with as

Probably the script output and its check should be enhanced
to distinguish between its failure and success with negative answer?
Or should the check be done under a condition like this?

	if not is_windows and (is_linux or cc.get_id() == 'gcc')


The next question is the preferred approach to fix things for Windows.
Current status:
1) MinGW 8.1.0 on Windows: buggy
2) MinGW 7.0.0 on Linux: OK
3) LLVM on Windows: OK

One solution is simply state this:

	if not is_windows
		binutils_bug_97 = ... # run the script
	elif cc.get_id() == 'gcc'
		binutils_bug_97 = true
	endif
	if binutils_bug_97
		machine_args += '-mno-avx512f'
		warning('...')
	endif

Another one is to make the script portable
and run it when LLVM is not used, on any OS, including cross builds.
By the way, $AS and objdump binaries may be overridden in a --cross-file,
so in this case we should locate them with meson.
What to others think?

Re: buildtools/binutils-avx512-check.sh

[Bruce Richardson]

On Fri, Nov 12, 2021 at 04:08:37PM +0300, Dmitry Kozlyuk wrote:
> Hello,
> 
> I'm working on improvement of Linux-to-Windows cross-compilation using MinGW.
> Currently there is c_args = '-mno-avx512f' in config/x86/cross-mingw, however,
> 1) baseline meson 0.49.2 doesn't like it*
> 2) it should be in machine_args because they are checked in various places
> 3) I don't like disabling AVX512F if there is really no issue**
> So I started looking at the subject script.
> 
> * '-mno-avx512f' should be ['-mno-avx512f'], but then the build of lib/net
>   breaks, because meson 0.49.2 and 0.57.0 (native Windows baseline)
>   order compiler arguments differently.
> 
> ** There was a .seh_savemm bug with MinGW that -mno-avx512f was trying to fix,
>    but I believe that -fno-asynchronous-unwind tables was the final solution.
>    However, AVX512 support is still broken for native MinGW builds, see below.
> 
> First question. In config/x86/meson.build we have:
> 
> # get binutils version for the workaround of Bug 97
> if not is_windows
>     binutils_ok = run_command(binutils_avx512_check)
>     if binutils_ok.returncode() != 0 and cc.has_argument('-mno-avx512f')
>         machine_args += '-mno-avx512f'
>         warning('Binutils error with AVX512 assembly, disabling AVX512
> support')
>     endif
> endif
> 
> This is a GNU binutils bug and if I understand correctly,
> it doesn't affect builds that use LLVM binutils (FreeBSD and Windows+clang).
> The script also uses ${AS:-as} and objdump, that may be missing.
> Consequently, AVX512F may be disabled for LLVM-based builds
> because GNU toolchain has a bug or is just absent:
> 
> root@freebsd:/tmp/dpdk # meson build
> [...]
> config/x86/meson.build:9: WARNING: Binutils error with AVX512 assembly,
> disabling AVX512 support
> [...]
> 
> root@freebsd:/tmp/dpdk # uname -r
> 13.0-RELEASE
> 
> root@freebsd:/tmp/dpdk # ./buildtools/binutils-avx512-check.sh
> ./buildtools/binutils-avx512-check.sh: as: not found
> ./buildtools/binutils-avx512-check.sh: objdump: not found
> vpgatherqq displacement error with as
> 
> Probably the script output and its check should be enhanced
> to distinguish between its failure and success with negative answer?
> Or should the check be done under a condition like this?
> 
> 	if not is_windows and (is_linux or cc.get_id() == 'gcc')
> 

That seems reasonable. At least in this case, the failure mode is fairly
safe as it always gives a correct build, but if it can be improved I have
no objection.

> 
> The next question is the preferred approach to fix things for Windows.
> Current status:
> 1) MinGW 8.1.0 on Windows: buggy
> 2) MinGW 7.0.0 on Linux: OK
> 3) LLVM on Windows: OK
> 
> One solution is simply state this:
> 
> 	if not is_windows
> 		binutils_bug_97 = ... # run the script
> 	elif cc.get_id() == 'gcc'
> 		binutils_bug_97 = true

The script still needs to be run here. Even in case of gcc, it's only a few
point releases of binutils that cause issues.

> 	endif
> 	if binutils_bug_97
> 		machine_args += '-mno-avx512f'
> 		warning('...')
> 	endif
> 
> Another one is to make the script portable
> and run it when LLVM is not used, on any OS, including cross builds.
> By the way, $AS and objdump binaries may be overridden in a --cross-file,
> so in this case we should locate them with meson.

Seems reasonable, and easy enough to fix.

> What to others think?