This is an archive of the discontinued LLVM Phabricator instance.

[Bugpoint redesign] Added option to run only certain delta passes
AbandonedPublic

Authored by diegotf on Aug 12 2019, 2:34 PM.

Details

Summary

This diff has been implemented to make llvm-reduce tests modular. Before, all the delta passes had to be run, thus interesting-ness tests had to add breaks so other passes didn't remove to-be-tested items.

It should be noted that this option is hidden, therefore it should only be accessed by tests!

Event Timeline

diegotf created this revision.Aug 12 2019, 2:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2019, 2:34 PM
diegotf edited the summary of this revision. (Show Details)Aug 12 2019, 2:37 PM
diegotf edited the summary of this revision. (Show Details)

I still feel like it'd probably be better to try to come up with some reliable/simple-enough idioms in the interestingness tests - rather than having more flags for the tool (even if they're only intended for test purposes).

I understand golden files in tests are usually not a great idea - but what would happen if the interestingness test was an exact IR file of the expected output, I wonder? Specifically the purpose being to demonstrate whether the reduction tool can get from the input to the output. Unlike other golden file situations that become hard to maintain as the tool changes its behavior, etc, in llvm-reduce the goal is that no matter how much better/different the tool gets, it can still manage every specific mapping from input to output.

diegotf abandoned this revision.Aug 14 2019, 3:32 PM

I still feel like it'd probably be better to try to come up with some reliable/simple-enough idioms in the interestingness tests - rather than having more flags for the tool (even if they're only intended for test purposes).

I understand golden files in tests are usually not a great idea - but what would happen if the interestingness test was an exact IR file of the expected output, I wonder? Specifically the purpose being to demonstrate whether the reduction tool can get from the input to the output. Unlike other golden file situations that become hard to maintain as the tool changes its behavior, etc, in llvm-reduce the goal is that no matter how much better/different the tool gets, it can still manage every specific mapping from input to output.

Fair enough. My main focus was simplifying the interesting-ness tests, but I can't argue with the last point. I'll go ahead and close this diff