This is an archive of the discontinued LLVM Phabricator instance.

[llvm][test] Split DW_AT_default_value check out of clang/test/
ClosedPublic

Authored by Michael137 on Dec 14 2022, 6:48 PM.

Details

Summary

Followup to D139953 to fix build failure on machines not
configured for x86.

Diff Detail

Event Timeline

Michael137 created this revision.Dec 14 2022, 6:48 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 14 2022, 6:48 PM
Michael137 requested review of this revision.Dec 14 2022, 6:48 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptDec 14 2022, 6:48 PM
Michael137 retitled this revision from [llvm][test] Split DW_AT_default_value check out of clang/test/ Followup to D139953 to fix build failure on machines not configured for x86. to [llvm][test] Split DW_AT_default_value check out of clang/test/.
Michael137 edited the summary of this revision. (Show Details)
  • Remove debug command
This revision was not accepted when it landed; it landed in state Needs Review.Dec 14 2022, 7:02 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Sorry, should've caught this in review. The clang change needs test coverage in clang, but should verify the emitted it, rather than going all the way down to object code.

The llvm functionality is already tested (since it's just the flag on a template parameter - it's not interesting to test that for different kinds of templates if the flag handling is kind-agnostic anyway)

So instead of this could you adjust the existing clang test to verify IR instead of dwarfdump?

Michael137 added a comment.EditedDec 15 2022, 7:02 AM

Sorry, should've caught this in review. The clang change needs test coverage in clang, but should verify the emitted it, rather than going all the way down to object code.

The llvm functionality is already tested (since it's just the flag on a template parameter - it's not interesting to test that for different kinds of templates if the flag handling is kind-agnostic anyway)

I couldn't find any test inside llvm/test which verifies that DW_AT_default_value is being emitted correctly. Sure we don't need a test like that?

So instead of this could you adjust the existing clang test to verify IR instead of dwarfdump?

@dblaikie Isn't the clang test already doing that? In this test I mainly wanted to check that the gstrict-dwarf attribute works as expected. The IR will always have the default attribute attached to it, which the clang/test/ already tests.

But if this new test is redundant I don't mind just removing it altogether

Sorry, should've caught this in review. The clang change needs test coverage in clang, but should verify the emitted it, rather than going all the way down to object code.

The llvm functionality is already tested (since it's just the flag on a template parameter - it's not interesting to test that for different kinds of templates if the flag handling is kind-agnostic anyway)

I couldn't find any test inside llvm/test which verifies that DW_AT_default_value is being emitted correctly. Sure we don't need a test like that?

I tried disabling the emission of DW_AT_default_value and running check-llvm to see what fails:

LLVM :: DebugInfo/X86/debug-info-default-template-parameter.ll
LLVM :: DebugInfo/X86/debug-info-template-parameter.ll

So, probably is tested already? (well, I guess the former is the one you just added, but the latter was already present - the latter could be modified to check the strict-dwarf behavior, but it's not a problem that you've added another test for that instead of trying to multiplex the existing test - all good either way, really)

So instead of this could you adjust the existing clang test to verify IR instead of dwarfdump?

@dblaikie Isn't the clang test already doing that? In this test I mainly wanted to check that the gstrict-dwarf attribute works as expected. The IR will always have the default attribute attached to it, which the clang/test/ already tests.

So the -gstrict-dwarf clang-side is somewhat hard to test because this property doesn't get encoded in the IR, it's only passed through as an TargetOption (this is generally not "ideal", and we'd rather use at least a module metadata, or a flag on the DICompileUnit - but tradeoffs be tradeoffs). Yeah, we either don't test it, or do make an exception and do an end-to-end test.

In this case, probably leave it untested at the Clang level.

At the LLVM level - it's testable, as you've found with the -strict-dwarf=true flag for llc.

(side note: when you send something for review through phab, please wait for approval before committing (otherwise it gets hard to tell what needed precommit review and may've been committed without it, versus things that weren't intended to be precommit reviewed - especially we don't want to give the impression that if you send something for review and don't receive a review quickly that it's OK to commit the patch anyway) - in this case, it might've been best to revert the original patch causing regressions if you weren't sure how to make a quick fix without precommit review - or to commit the fix directly & discuss it further post-commit if you wanted some more feedback to see if that was the ideal direction)