This is an archive of the discontinued LLVM Phabricator instance.

llvm-reduce: Try to kill parallel workitems once we have a result.
AcceptedPublic

Authored by arsenm on Nov 29 2022, 2:31 PM.

Details

Summary

The current reduction logic tries to reproduce what a serial reduction
would produce, and just takes the first one that is still
interesting. We still have to wait for all others to complete though,
which at that point is just a waste.

This helps speed things up with long running reducers, which I
frequently have. e.g. for the added sleep test on my system, it took
about 8 seconds before this change and about 4 after.

Diff Detail

Event Timeline

arsenm created this revision.Nov 29 2022, 2:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 29 2022, 2:31 PM
arsenm requested review of this revision.Nov 29 2022, 2:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 29 2022, 2:31 PM
Herald added a subscriber: wdng. · View Herald Transcript

just fyi, the experience with this from C-Reduce is that first, killed compilers will tend to leave crap in /tmp or similar, and this builds up over time, but usually not that quickly.

and second, this only worked robustly when I made a new process group to put the interestingness test into and then killed the entire group.

arsenm updated this revision to Diff 479440.Dec 1 2022, 2:46 PM

Rebase on optional change

arsenm added a comment.Dec 1 2022, 2:47 PM

just fyi, the experience with this from C-Reduce is that first, killed compilers will tend to leave crap in /tmp or similar, and this builds up over time, but usually not that quickly.

opt and llc don't do this, so I'm not too worried about this. Not sure what I would try to do about this anyway since tools tend to make up their own random unique filenames.

and second, this only worked robustly when I made a new process group to put the interestingness test into and then killed the entire group.

Do you expect that in this patch? I don't see an existing abstraction for this

regehr added a comment.Dec 1 2022, 3:06 PM

just fyi, the experience with this from C-Reduce is that first, killed compilers will tend to leave crap in /tmp or similar, and this builds up over time, but usually not that quickly.

opt and llc don't do this, so I'm not too worried about this. Not sure what I would try to do about this anyway since tools tend to make up their own random unique filenames.

probably the best option (only supported by some tools) is to tell the tool what tmp directory it should use, and then arrange for this to be removed when the reducer terminates.

and second, this only worked robustly when I made a new process group to put the interestingness test into and then killed the entire group.

Do you expect that in this patch? I don't see an existing abstraction for this

fine to defer this (and the thing above) until needed, but please add a TODO sorta thing reminding us that we might want to do this later

also when testing/using this functionality, definitely keep an eye out for things that keep running past when you try to kill them, because you didn't actually kill them but only killed some other process

just fyi, the experience with this from C-Reduce is that first, killed compilers will tend to leave crap in /tmp or similar, and this builds up over time, but usually not that quickly.

opt and llc don't do this, so I'm not too worried about this. Not sure what I would try to do about this anyway since tools tend to make up their own random unique filenames.

probably the best option (only supported by some tools) is to tell the tool what tmp directory it should use, and then arrange for this to be removed when the reducer terminates.

and second, this only worked robustly when I made a new process group to put the interestingness test into and then killed the entire group.

Do you expect that in this patch? I don't see an existing abstraction for this

fine to defer this (and the thing above) until needed, but please add a TODO sorta thing reminding us that we might want to do this later

also when testing/using this functionality, definitely keep an eye out for things that keep running past when you try to kill them, because you didn't actually kill them but only killed some other process

Core files are now turned off by default as of 95abdeba6152c3fa15e96b4bababe6311bc9c118

sorry, just got back from vacation, will try to look at this (and all your other patches) sometime this week

fhahn accepted this revision.Jan 10 2023, 9:56 AM

LGTM, thanks! Might be good to wait with landing until tomorrow in case @aeubanks or anybody else has additional comments.

llvm/tools/llvm-reduce/ReducerWorkItem.h
19

is this include need here? Seems like nothing from <atomic> is used here.

llvm/tools/llvm-reduce/TestRunner.cpp
79

nit: might be good to use early exit to reduce indent?

This revision is now accepted and ready to land.Jan 10 2023, 9:56 AM
arsenm marked an inline comment as done.Jan 11 2023, 5:46 AM
arsenm added inline comments.
llvm/tools/llvm-reduce/TestRunner.cpp
79

Switched to while loop to reduce indent

84–86

I also fixed this problem, so I've switched this to a 0 second timeout. sys::Wait now uses optional, and distinguishes nullopt=wait infinity and 0 is expect immediate exit

arsenm reopened this revision.Jan 11 2023, 4:24 PM
This revision is now accepted and ready to land.Jan 11 2023, 4:24 PM
arsenm updated this revision to Diff 488419.Jan 11 2023, 4:26 PM

New test, make test work. Test takes way longer than I would like now for some reason