I have a test that checks for specific asm sequences emitted by clang.
Unsurprisingly, the test fails if clang is built without support for the
target in question.
Unfortunately, I can't have the test emit LLVM IR because that won't
contain what I need to test. I can't make it an LLVM test because I'm
testing the interaction of options to clang.
How does cmake/lit decide whether tests in test/CodeGen should be run or
not? Take test/CodeGen/x86.c. It's looking for register name specific
to an x86 target. How does the testing infrastructure know not to run
this test if clang is built without support for x86?
-David
Hi David,
Unfortunately, I can't have the test emit LLVM IR because that won't
contain what I need to test. I can't make it an LLVM test because I'm
testing the interaction of options to clang.
There ought to be *some* trace, either in the cc1 options (in which
case you'd write a Driver test and an LLVM one), or in the IR. That
said, I won't second guess you...
How does cmake/lit decide whether tests in test/CodeGen should be run or
not? Take test/CodeGen/x86.c. It's looking for register name specific
to an x86 target. How does the testing infrastructure know not to run
this test if clang is built without support for x86?
That particular test doesn't need a backend because it only checks
LLVM IR. But what you're looking for is "REQUIRES:
x86-registered-target" (or similar if you're not testing x86).
Cheers.
Tim.
Hi David,
Unfortunately, I can’t have the test emit LLVM IR because that won’t
contain what I need to test. I can’t make it an LLVM test because I’m
testing the interaction of options to clang.
There ought to be some trace, either in the cc1 options (in which
case you’d write a Driver test and an LLVM one), or in the IR.
There are some small gaps - where the interaction between Clang and LLVM is purely done via API, rather than command line or IR. For example things like MCOptions, TargetOptions, etc - if you change Clang to compute the parameters to those options differently (or regressed that functionality by not initializing those options correctly, etc) pure clang (command line + source => IR) or LLVM (IR => assembly), etc, couldn’t catch it. In many cases those options can be moved to the IR, but some don’t make sense/need to be there.
That
said, I won’t second guess you…
I will a little bit - it’d be good to see the thing being tested just to understand if it is one of those gaps.
Tim Northover <t.p.northover@gmail.com> writes:
Hi David,
Unfortunately, I can't have the test emit LLVM IR because that won't
contain what I need to test. I can't make it an LLVM test because I'm
testing the interaction of options to clang.
There ought to be *some* trace, either in the cc1 options (in which
case you'd write a Driver test and an LLVM one), or in the IR. That
said, I won't second guess you...
Possibly. I will think a bit harder. A Driver test may be what I'm
looking for.
How does cmake/lit decide whether tests in test/CodeGen should be run or
not? Take test/CodeGen/x86.c. It's looking for register name specific
to an x86 target. How does the testing infrastructure know not to run
this test if clang is built without support for x86?
That particular test doesn't need a backend because it only checks
LLVM IR. But what you're looking for is "REQUIRES:
x86-registered-target" (or similar if you're not testing x86).
Ok, thanks.
-David
David Blaikie <dblaikie@gmail.com> writes:
That
said, I won't second guess you...
I will a little bit - it'd be good to see the thing being tested just
to understand if it is one of those gaps.
Well it turns out you both were right to second-guess. I already had
LLVM tests to check the functionality, I just needed to make sure clang
was setting the right things in LLVM. Driver tests were exactly what I
needed. Thanks!
I have come across the need to do the things David mentiones (setting
TargetOptions, etc.) so I agree there's a gap.
-David