[compiler-rt] [compiler-rt] Add infrastructure for testing cpuid builtins (PR #101927)
Aiden Grossman via llvm-commits
llvm-commits at lists.llvm.org
Sun Dec 1 22:33:29 PST 2024
boomanaiden154 wrote:
> Using OverrideCPUID doesn't look an ideal solution to me. It cannot prevent mistakes from author who wrote both code and test.
Right. It can't catch everything, but it should be an improvement over what we have currently (no testing). I'm also not sure there's anything that is clearly better and works across vendors. My plan for this was ideally to take raw cpuid values from real hardware and then assert that we get the expected features and identify the appropriate CPU. That doesn't make it foolproof, but should be a reasonable enough approach.
> It also cannot reflect any HW changes or mismatch.
Can you explicate on the specific scenarios you're describing here?
> I'd like to see run time test from llvm-test-suite. We can leverage SDE to emulate different Intel CPUs, but I don't know how to do with other vendors.
I would think using SDE would require adding it as a dependency to `llvm-test-suite` for running these tests, which I don't think would be trivial, and would significantly limit the total number of machines that run these tests. I'd also like to test AMD CPU values as well.
I think we could write a hook that uses `ptrace` as I believe the `rr` folks added some kernel support to trap around `cpuid` instructions, but that would put us back in the same spot as your first comment, and at that point I think unittests are easier to write and maintain.
https://github.com/llvm/llvm-project/pull/101927
More information about the llvm-commits
mailing list