Page MenuHomePhabricator

[bugpoint] Try to reduce passes after reducing everything.
ClosedPublic

Authored by fhahn on Oct 20 2019, 9:55 PM.

Details

Summary

In some cases, we fail to reduce the pass list earlier because of
complex pass dependencies, but we can reduce it after we simplified the
reproducer.

An example of that is PR43474, which can limit the crash to
-loop-interchange. Adding a test case would require at least 2
interacting Loop passes I think.

Diff Detail

Event Timeline

fhahn created this revision.Oct 20 2019, 9:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2019, 9:55 PM
reames accepted this revision.Oct 28 2019, 11:11 AM

LGTM.

On a general note, I think we should be iterating to a fixed point between the various reductions. There's no reason we should ever be returning something another run of bugpoint could reduce. We'd need to provide a "fast" mode of course, but that seems worthwhile anyways.

This revision is now accepted and ready to land.Oct 28 2019, 11:11 AM
fhahn added a comment.Oct 29 2019, 6:56 AM

LGTM.

On a general note, I think we should be iterating to a fixed point between the various reductions. There's no reason we should ever be returning something another run of bugpoint could reduce. We'd need to provide a "fast" mode of course, but that seems worthwhile anyways.

That's an interesting suggestion!

My main motivation for the initial set of recent bugpoint patches was to see how easy it would be to fix a few pain points I've seen in the past (and to kill some time on a plane). The initial patches were quite small, because I do not have any experience with the bug point code, the test coverage is really limited and I wanted to avoid breaking bugpoint. But I think once the first set of patches are committed and baked a bit, I would like to explore the direction suggested a bit more.

This revision was automatically updated to reflect the committed changes.