Closed kostadinsh closed 6 months ago
CC @phoebewang
@llvm/issue-subscribers-backend-x86
Author: Kostadin (kostadinsh)
I think the error is expected. Using -march=native
on 13600KF will turn off all avx512 features as well as evex512. The problem here is the command adding an extra -mavx512vl
, so the frontend interprets it as -mavx512vl -mno-evex512
. With this combination, compiler is reasonable to error when compiling 512-bit instructions.
I think it doesn't make sense to compile -march=native
with extra features. In this case, you can either remove -mavx512vl
or add extra -mevex512
together.
the -mavx512vl flag wasn't added by me tho. It was added by the build system somehow.
Same for me, i have no idea why clang trying to compile avx512 file, but in fact - clang is trying to use -mavx512vl specifically for blake3_avx512_x86-64_unix.S.o
I'm not familar with cmake settings. Maybe file another issue to cmake?
@phoebewang Let me describe the situation when such problems appear. First, we have some libraries/applications use runtime cpu dispatching -- essentially building some code with different architecture flags and then selecting between implementations in runtime by querying cpuid. Build systems for such projects are intentionally configured to inject additional flags during the build -- flags like -mavx512xxx
for avx512-version of implementation. Second, we have the project consumers who build the project from source and use -march=native
. In particular, Gentoo Linux allows its users to build system packages from sources in such manner.
I think it doesn't make sense to compile
-march=native
with extra features.
Well, it might as well be when we have a single party, but in this case there are two parties and intentions of both of them are somewhat reasonable.
Then we have a question regarding consistency. -march=sandybridge -mavx512f -mavx512vl
does not have a lot of sense either, but it will enable avx512
and evex512
nonetheless. -march=native -mavx512f -mavx512vl
for processors before avx512
/avx10
will effectively use -mavx512f -mavx512vl -mno-evex512
which in turn enables __AVX512F__
, __AVX512VL__
, __EVEX256__
-- essentially meaning avx10-256
and that is a bad take on the situation:
$ clang++ -march=native -mavx512f -mavx512vl -dM -E -v - </dev/null 2>&1 | grep 'AVX512\|EVEX'
#define __AVX512F__ 1
#define __AVX512VL__ 1
#define __EVEX256__ 1
It appears to me that it would be better either to explicitly disallow usage of -march=native
together with additional arch options like -mavx512f
(we will not silently end up with avx10-256
instead of expected avx512
) or to avoid assuming -mno-evex512
when processing -march=native
similarly to how -march=sandybridge
works (which also does not have evex512
feature, but -mno-evex512
is not assumed in this case). Personally, I would prefer the second option as it is both more consistent and fixes the above-mentioned usecase.
@llvm/issue-subscribers-clang-driver
Author: Kostadin (kostadinsh)
Then we have a question regarding consistency.
-march=sandybridge -mavx512f -mavx512vl
does not have a lot of sense either, but it will enableavx512
andevex512
nonetheless.-march=native -mavx512f -mavx512vl
for processors beforeavx512
/avx10
will effectively use-mavx512f -mavx512vl -mno-evex512
which in turn enables__AVX512F__
,__AVX512VL__
,__EVEX256__
-- essentially meaningavx10-256
and that is a bad take on the situation:
Makes sense to me. Created https://github.com/llvm/llvm-project/pull/91694 for this, PTAL, thanks!
I also hit this issue and submitted a bug report for it to Gentoo's Bugzilla instance; that's https://bugs.gentoo.org/931656.
LLVM fails to build when using
-march=native
on an Intel Core i5 13600KF, reproducible both on master at https://github.com/llvm/llvm-project/commit/cb015b9ec9446b3a1303980c095fa442d5e46fbf and version 18.1.5Output from `echo | clang -E - -march=native -###
complete build log from portage