For more background, this approach was copied from AArch64 SVE where they said this was beneficial to catch warnings from TypeSize's implicit conversion to uint64_t.
IMO, this is also useful to catch mismatch in generated IR intrinsic with backend because we have llvm_any_ty type in intrinsic IR . In the downstream we met the same bug several time which generated intrinsic from builtin can not be selected in backend, and it
Do you mean we need to add the IR tests which are generated by clang builtin?
I don't like to add too much IR tests, so I'm OK to remove ASM test. But in the future, reviewer maybe need to verify the generated IR can generate asm without any error.
I'm conflicted on this.
Given how the IR intrinsics are making heavy use of any_ty we lose a lot of type checking in the intrinsic creation. We've had multiple case where the intrinsics the types the frontend generated were different than what the backend tests were testing. So from that perspective, the end-to-end tests have value.
I don't really like the idea of having two copies of every test. Maybe we could have multiple test files that use a common Input file?
I'm not completely convinced it is important to be able to test the IR gen without the backend being built. The most likely changes that would cause the -emit-llvm tests to fail or need to be updated are changes to RISCV specific code in the .td file, our tablegen backend, or CGBuiltin.cpp. I would expect a RISCV developer touching those files to be compiling the RISCV backend.