This is an archive of the discontinued LLVM Phabricator instance.

[bugpoint] Actually skip a modules that cause verifier errors
Needs ReviewPublic

Authored by loladiro on May 11 2018, 6:54 PM.

Details

Reviewers
aprantl
Summary

When reducing modules, it is possible for us to introduce changes
that fail the verifier. The intent was for these modules to get skipped
such that we would try a different reduction instead. However, it
seems that while we did the verification, we nevertheless proceeded
with the broken module. Make sure to actually check for a broken module.

Diff Detail

Event Timeline

loladiro created this revision.May 11 2018, 6:54 PM

Since we regressed on this before: could you come up with a testcase for this?

Yeah, I've been thinking about what the best way to test this is. It seems somewhat hard to reliably trigger
a verifier fault by removing an instruction - llvm.stackprotector is the one I see most commonly, but I don't
really want to make the test depend on that behavior. One option is to teach bugpoint to use a custom verifier
pass and then write a custom verifier pass that e.g. checks for the presence of a call. That seems like a decently
attractive option, because it would be a useful feature in its own right. Some frontends have their own invariants
and corresponding verifier passes that they want to maintain in their early passes. Would be nice if bugpoint could
support that. The only thing I'm not quite sure off is to how to do this nicely. Presumably, we could use the analysis
name as a pass and run that through the pass manager. I'm just not sure how to get the analysis result out of that.