[AArch64] LLVM 20 regression when generating NEON instructions for ARMv9-A with SVE disabled

[ptosi]

Hi,

we have noticed a regression between Clang v19.0.1 and Clang v20.0.0 when compiling code targeting NEON for ARMv9-A with SVE disabled.

The following:

#include <arm_neon.h>

uint16x8_t vec_fma(uint16x8_t a, uint16x8_t b, uint16_t c)
{
        return vmlaq_n_u16(a, b, c);
}

compiles with

clang -target aarch64-linux-gnu -march=armv9.2-a -O2 -Xclang -target-feature -Xclang -sve -c "neon.c"

to

0000000000000000 <vec_fma>:
   0:   4e020c02        dup     v2.8h, w0
   4:   4e619440        mla     v0.8h, v2.8h, v1.8h
   8:   d65f03c0        ret

with (Android build)

Android (12833971, +pgo, +bolt, +lto, +mlgo, based on r536225) clang version 19.0.1 (https://android.googlesource.com/toolchain/llvm-project b3a530ec6537146650e42be89f1089e9a3588460)

However, the same invocation fails:

neon.c:4:9: error: always_inline function 'vmlaq_n_u16' requires target feature 'sve', but would be inlined into function 'vec_fma' that is compiled without support for 'sve'
    4 |         return vmlaq_n_u16(a, b, c);
      |                ^

with

Android (13016439, +pgo, +bolt, +lto, +mlgo, based on r547379) clang version 20.0.0 (https://android.googlesource.com/toolchain/llvm-project b718bcaf8c198c82f3021447d943401e3ab5bd54)

instead of generating the NEON instructions, as expected.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Pierre-Clément Tosi (ptosi)

Hi,

we have noticed a regression between Clang v19.0.1 and Clang v20.0.0 when compiling code targeting NEON for ARMv9-A with SVE disabled.

The following:

#include <arm_neon.h>

uint16x8_t vec_fma(uint16x8_t a, uint16x8_t b, uint16_t c)
{
        return vmlaq_n_u16(a, b, c);
}

compiles with

clang -target aarch64-linux-gnu -march=armv9.2-a -O2 -Xclang -target-feature -Xclang -sve -c "neon.c"

to

0000000000000000 <vec_fma>:
   0:   4e020c02        dup     v2.8h, w0
   4:   4e619440        mla     v0.8h, v2.8h, v1.8h
   8:   d65f03c0        ret

with (Android build)

Android (12833971, +pgo, +bolt, +lto, +mlgo, based on r536225) clang version 19.0.1 (https://android.googlesource.com/toolchain/llvm-project b3a530ec6537146650e42be89f1089e9a3588460)

However, the same invocation fails:

neon.c:4:9: error: always_inline function 'vmlaq_n_u16' requires target feature 'sve', but would be inlined into function 'vec_fma' that is compiled without support for 'sve'
    4 |         return vmlaq_n_u16(a, b, c);
      |                ^

with

Android (13016439, +pgo, +bolt, +lto, +mlgo, based on r547379) clang version 20.0.0 (https://android.googlesource.com/toolchain/llvm-project b718bcaf8c198c82f3021447d943401e3ab5bd54)

instead of generating the NEON instructions, as expected.

[efriedma-quic]

It looks like this is specifically caused by the use of -Xclang -target-feature -Xclang -sve. Which isn't a supported interface, so this is sort of self-inflicted. But maybe there's some way to make the behavior here more friendly.

I'm not sure exactly what code is relevant here off the top of my head; a bisect might be helpful.

[jroelofs]

It looks like this is specifically caused by the use of -Xclang -target-feature -Xclang -sve. Which isn't a supported interface, so this is sort of self-inflicted. But maybe there's some way to make the behavior here more friendly.

IMO the root of that problem is that SVE is optional in v9.2, but LLVM (poorly) treats it as opt-out.

[efriedma-quic]

I won't get into that argument... but -march=armv9.2-a+nosve works fine. Only the "-Xclang" form is broken.

[davemgreen]

This might have started in [Clang][NEON] Add neon target guard to intrinsics (#99870), which was when these particular intrinsics first had target features added to them. It would have happened before that with intrinsics that require targets like vqrdmlahq_s16. It looks like Reland "[AArch64] Decouple feature dependency expansion. (#94279)" (#95519) is when the behaviour changed.

It is strange that the compiler is getting confused and thinking it needs +sve, but the correct way would be to use -march=armv9.2-a+nosve.

[ptosi]

Which isn't a supported interface, so this is sort of self-inflicted

the correct way would be to use -march=armv9.2-a+nosve

I don't disagree; however our current build setup makes this somewhat complicated, unfortunately.

It is strange that the compiler is getting confused and thinking it needs +sve

Exactly. I am not asking for a stable CLI, here, only to fix what seems to be an unintentional low-level bug in LLVM.

[efriedma-quic]

CC @labrinea @tmatheson-arm

[labrinea]

Hi, I am on vacation. I can look into this next week.

[labrinea]

@ptosi the instrinsic you are using is guarded with __attribute__((target("neon"))). The diagnostics are emitted inside CodeGenFunction::checkTargetFeatures. I am not sure what exactly is going on, but as others have said passing llvm backend features to clang is not supported. There seems to be a mismatch between the feature maps of caller and callee. I suppose when parsing the target attribute which guards the callee, the -XClang option is ignored, or something like that.