This is an archive of the discontinued LLVM Phabricator instance.

stop llvm-reduce from introducing undefs
ClosedPublic

Authored by regehr on Jun 21 2022, 6:34 PM.

Details

Summary

this patch removes the operands-undef pass and also modifies several other passes that try to introduce undef to instead introduce a "default value" which at the moment is just the zero value.

it leaves an undef in ReduceRegisterUses.cpp, I leave fixing that as future work since I don't know much about MIR and don't to mess things up.

why do we want this patch? the major reason is because the client for reduced IR files is usually a human being, and we know that human beings are not that great about reasoning about undef. it's just really hard -- we'd often prefer a slightly bigger test case that doesn't contain undefs. the second reason is because undef is very difficult for alive2, and we're trying to develop an automated bugfinding workflow that relies on llvm-reduce, and getting gratuitous undefs is just a bad thing for that use case.

Diff Detail

Event Timeline

regehr created this revision.Jun 21 2022, 6:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2022, 6:34 PM
Herald added subscribers: nlopes, mgorny. · View Herald Transcript
regehr requested review of this revision.Jun 21 2022, 6:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 21 2022, 6:34 PM
aeubanks accepted this revision.Jun 22 2022, 2:46 PM

makes sense to me

llvm/tools/llvm-reduce/deltas/Utils.cpp
19

PoisonValue?

19

looking at Constant::getNullValue, looks like labels also don't have a null value, but I guess we're not using this with labels

This revision is now accepted and ready to land.Jun 22 2022, 2:46 PM
regehr marked an inline comment as done.Jun 22 2022, 6:08 PM
regehr added inline comments.Jun 22 2022, 6:18 PM
llvm/tools/llvm-reduce/deltas/Utils.cpp
19

my take is it's not worth putting an assert on this since if a label goes into Constant::getNullValue() it'll hit the llvm_unreachable there, which is about as useful as hitting an assert

regehr updated this revision to Diff 439235.Jun 22 2022, 6:32 PM

clang-format and address review

This revision was landed with ongoing or failed builds.Jun 22 2022, 7:41 PM
This revision was automatically updated to reflect the committed changes.
arsenm added a subscriber: arsenm.Jun 27 2022, 10:33 AM

I don't agree with this change. I definitely don't agree with changing the MIR reduction. I would say most of the value I've received from bugpoint and llvm-reduce is in finding bugs from mishandling undefs

I don't agree with this change. I definitely don't agree with changing the MIR reduction. I would say most of the value I've received from bugpoint and llvm-reduce is in finding bugs from mishandling undefs

If the original test case had undef, it is kept. This change just prevents introduction of more undefs.
llvm-reduce is not a fuzzer, so its job is not to create weird programs to find new bugs. I agree fuzzers should create programs with undef and everything else.

hi Matt, I wanted first to echo what Nuno said and second say that if this change is somehow detrimental to performing test case reductions that you care about, please send me the specific example (or maybe just post it on discourse and tag me) and let's figure out what to do about it. My hope and belief here are that this probably won't happen, but you never know.

Also, notice that this patch takes a bunch of program points that introduce undef and makes them all point to a getDefaultValue() function that we can trivially modify to start adding undefs again, perhaps protected by a command line argument, if that ended up being desirable. I'll make that change if it would benefit you. (But I still strongly believe that decreasing the number of undefs or at least leaving it unchanged is the correct default for basically any standard use case for llvm-reduce.)