[clang] [llvm] [AArch64TargetParser]Fix reconstructFromParsedFeatures ignoring negative features (PR #142236)

[Alexandros Lamprineas via llvm-commits]

labrinea wrote:

> The original situation looks something like:
> 
> ```
> #include <arm_neon.h>
> 
> void foo() {
>    // ...
>    uint8x16_t x = {};
>    vreinterpretq_u8_s8(x);
> }
> ```
> 
> Compiled with `clang -target aarch64-redhat-linux-gnu -march=-march=armv9-a+sve2+fp16+fp16fml+crypto+bf16+sm4+i8mm+sve2-bitperm+sve2-sha3+sve2-aes+sve2-sm4 -Xclang -target-feature -Xclang -sve -c test.c` (coming from a build system where `-target, -march` flags are set centrally but this particular target/team not being able to handle SVE appended the `-Xclang` flags for their target)...
> 
> This compiled fine in clang-17, but with the clang-19 the frontend started producing this confusing message (because this is a neon intrinsic, not an SVE one):
> 
> ```
> test.cpp:5:3: error: always_inline function 'vreinterpretq_u8_s8' requires target feature 'sve', but would be inlined into function 'foo' that is compiled without support for 'sve'
>     5 |   vreinterpretq_u8_s8(x);
> ```

Well, with your patch this now compiles, but the unit test demonstrates that none of the extensions of that command line which depend on sve (like sve2, sve2-bitperm, etc) will get disabled. I doubt this was the intention. Passing internal frontend options with -Xclang is not recommended.

I tried modifying`reconstructFromParsedFeatures` by replacing `Enabled.reset()` with `disable()`and `Enabled.set()` with `enable()`but that made 50 clang tests fail with errors similar to the one you reported (mismatch between target features of caller and callee).

https://github.com/llvm/llvm-project/pull/142236