Remove the checking of the generated asm, as that's already tested elsewhere, and adjust some tests that were expecting the wrong intrinsic to be generated.
Details
Diff Detail
Event Timeline
Does this clang test actually need to check the generated assembly? Shouldn't it be enough to check that the correct intrinsics are generated?
I could remove the CHECK-ASM checks, but the other xyz-constrained.c tests (including non-aarch64 ones) all do this and it feels a bit weird to just do that to this test.
I guess the question is if there is a convincing reason to check the assembly in this test? Unless it is required for the test, checking for assembly makes the test more fragile than they need to be. Also, is there any difference in the generated IR between X86 and AArch64? If not, the tests should probably be unified.
llvm/test/CodeGen/AArch64/fp-intrinsics-vector.ll is testing the asm generation, so it probably is fine to remove that here so I will. This test is specifically testing arm_neon.h intrinsics though, so wouldn't make sense unifying with other architectures.
It's been a while, but I think the aarch64-neon-intrinsics-constrained.c test is trimmed down from the aarch64-neon-intrinsics.c test. Shouldn't the constrained and non-constrained end-to-end tests be treated the same?
Are you referring to https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGen/aarch64-neon-intrinsics.c? This one doesn't check assembly.
Ah, well, I guess that wasn't it, then. It's been a while, and I've been all over the place.
A clang-only test that just tests for the correct IR being emitted won't trigger the failures in the backend. An LLVM-only test that starts from that IR can show those failures, but it also runs the risk over time of getting out of sync with the IR emitted by clang. An end-to-end test will always be in sync, and it will show those failures that I ran into plus anything else that crops up over time. If there's another way, or if there is another approach, then it might be possible there's a way to get all the testing done without running into those issues. I just don't know what it is.
Also adjust aarch64-v8.2a-fp16-intrinsics-constrained.c in this patch (was previously done in
D115620) and remove the checks of the generated asm.