This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel][Legalizer] LegalizerInfo verifier: checking that legalization rules cover all type indices
ClosedPublic

Authored by rtereshin on May 1 2018, 4:09 PM.

Details

Summary

This patch adds a simple verifier that tracks type indices being touched by legalization rules' builders.

Every target will now have an opportunity to call LegalizerInfo::verify(...) at the end of its derived LegalizerInfo's constructor and check there are no obvious mistakes like checking only first type for an opcode that has more than one type index and therefore implicitly declaring any type for the second (and higher) type index legal.

The check is only ran in assert builds and should have very minor performance impact in assert builds and none in release builds.

This patch also doesn't make the verification errors fatal, only produces an error message, there is a follow up patch that does.

This is inspired by the discussion at https://reviews.llvm.org/D44704, please take a look there for more info on motivation.

This patch includes 2 commits:

the first is described above, it does not add LegalizerInfo::verify(...) calls to target-specific legalizers;

the second one has the following message:

[GlobalISel][AArch64] LegalizerInfo verifier: Adding LegalizerInfo::verify(...) call w/o fixing bugs
 
This is to make it clear what kind of bugs the LegalizerInfo::verifier
is able to catch and test its output

I also have an NFC commit planned to get in before this patch with the following commit message:

[GlobalISel][Legalizer] LegalizerInfo NFC, mostly reducing LegalizeRuleSet's methods' inter-dependecies

Making LegalizeRuleSet's implementation a little more dumb and
straightforward to make it easier to read and change, in particular in
order to add the initial version of LegalizerInfo verifier

Diff Detail

Repository
rL LLVM

Event Timeline

rtereshin created this revision.May 1 2018, 4:09 PM
rtereshin added inline comments.May 1 2018, 11:58 PM
include/llvm/CodeGen/GlobalISel/LegalizerInfo.h
371

"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Greenspun's tenth rule of programming. 1993

Couple of nits on the tests.

test/CodeGen/AArch64/GlobalISel/legalize-inttoptr-xfail-1.mir
3

Could you add a comment explaining what you are testing in this test case?
Basically why is it useful? :)

Shouldn't we run not llc?

test/CodeGen/AArch64/GlobalISel/legalize-inttoptr-xfail-2.mir
3

Ditto.

rtereshin added inline comments.May 3 2018, 5:07 PM
test/CodeGen/AArch64/GlobalISel/legalize-inttoptr-xfail-1.mir
3

It's useful because it makes it obvious what kind of bugs we're missing w/o some kind of validation for LegalizerInfo. I guess I should add a comment saying exactly that :)

And the test passes, that's the point. So no not llc. Or you want not llc and XFAIL both in the same file?

rtereshin added inline comments.May 3 2018, 6:14 PM
test/CodeGen/AArch64/GlobalISel/legalize-inttoptr-xfail-2.mir
3

I think I'm going to put a not llc in the follow up (https://reviews.llvm.org/D46414), and then make these tests here in his patch exactly the same, but with XFAIL. And put the comment as suggested above. That would probably make most sense.

rtereshin updated this revision to Diff 145130.May 3 2018, 6:49 PM
rtereshin marked 2 inline comments as done.

Updated the xfail tests to make their purpose clearer.

rtereshin added inline comments.May 7 2018, 2:53 PM
lib/CodeGen/GlobalISel/LegalizerInfo.cpp
99

@qcolombet
+ @dsanders

I'll update the tests as requested in https://reviews.llvm.org/D46339 in a bit, in the meantime, I'm wondering, if it makes sense to check that we don't cover more type indices than there is as well, not just less.

It looks like in practice such mistakes are much less common, also, checking more type indices then needed fails much easier on an assertion while accessing an out of bounds item of the LegalityQuery::Types ArrayRef anyway. However, such a check is much more dynamic in a sense that it will only happen if there is a test that triggers a creation of such a query, while the verification proposed here despite not being strictly speaking static still catches issues as soon as a legalizer for a particular target is instantiated, so in practice, any test suffices.

What do you think?

Also, what do you think on the idea in general? I'm not particularly insisting that this patch is a good thing.

rtereshin updated this revision to Diff 145696.May 8 2018, 8:48 AM

Adding comments to the tests as requested.

rtereshin updated this revision to Diff 146424.May 11 2018, 3:21 PM

Removing -simplify-mir command line options from run-lines.

@qcolombet Is this one good to go as well as the follow up or not quite?

Thanks for looking into this!

Roman

aemerson accepted this revision.May 28 2018, 10:35 AM

Overall I'm in favour of this change, so LGTM.

lib/CodeGen/GlobalISel/LegalizerInfo.cpp
553

This will need to be LLVM_DEBUG now I think.

This revision is now accepted and ready to land.May 28 2018, 10:35 AM
This revision was automatically updated to reflect the committed changes.