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.
Details
- Reviewers
aprantl
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 18024 Build 18024: arc lint + arc unit
Event Timeline
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.