This is an archive of the discontinued LLVM Phabricator instance.

[bugpoint] Don't stop reducing when verification fails, keep trying
Needs RevisionPublic

Authored by vsk on Feb 8 2018, 9:22 PM.

Details

Reviewers
davide
MatzeB
Summary

Instead of calling exit() when a verification step fails we should keep
reducing the input. This is in line with what we do in other cases when
opt fails (see performFinalCleanups(), extractLoop(), etc).

I have a test case that provides coverage for this change, but it's
large and (for now) relies on an uncommitted assertion in SelectionDAG.

I don't think it's worthwhile to test this change in-tree because a
bugfix to a bugpoint reducer could break the test. (It would be fair to
say that the real problem I'm having is that some reducer is buggy, and
that I could just try to fix that instead, but unless we instantly fix
all reducer bugs having this "keep going" behavior sgtm. Thoughts?)

Diff Detail

Event Timeline

vsk created this revision.Feb 8 2018, 9:22 PM
vsk updated this revision to Diff 133563.Feb 8 2018, 9:40 PM
  • Fixed up a test.
davide requested changes to this revision.Feb 9 2018, 10:48 AM

Did you get a sense of why we can't remove the instructions? This is probably something we want anyway, but there could be another bug in llvm (or bugpoint itself, as instruction deletion is always supposed to succeed).

This revision now requires changes to proceed.Feb 9 2018, 10:48 AM

marking as "requesting changes" so it gets out of my queue

vsk added a comment.Feb 9 2018, 11:51 AM

Did you get a sense of why we can't remove the instructions? This is probably something we want anyway, but there could be another bug in llvm (or bugpoint itself, as instruction deletion is always supposed to succeed).

Yep, it was completely my fault. I specified the wrong path to my opt binary, so runPassesOn() silently failed with 'file not found'. I added a warning: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180205/523911.html.

But.. I haven't devoted any time to figuring out why the bugpoint invocation in unsymbolized.ll hit the "exit(1)" path before this change. I'll need to figure that out before landing this.