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.
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?
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.