This is an archive of the discontinued LLVM Phabricator instance.

llvm-reduce: Don't write out IR to score IR complexity
ClosedPublic

Authored by arsenm on Oct 9 2022, 9:03 AM.

Details

Summary

In a testcase I'm working on, the old write out and count IR lines
was taking about 200-300ms per iteration. This drops it out of the
profile.

This doesn't account for everything, but it doesn't seem to matter.
We should probably try to account for metadata and constantexpr tree
depths.

Diff Detail

Event Timeline

arsenm created this revision.Oct 9 2022, 9:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 9 2022, 9:03 AM
arsenm requested review of this revision.Oct 9 2022, 9:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 9 2022, 9:03 AM
Herald added a subscriber: wdng. · View Herald Transcript

so at some level here we're scoring a test case based on how simple it is for a human being to understand. I mean, that's what we should be doing. from that point of view, I dislike assigning a small cost to poison and undef -- they're probably the most semantically challenging concepts in this entire IR, in terms of the number of compiler bugs they have caused.

I think that fast-math and other flags (especially ones like NSW) should be accounted for here, but if that's left for future work that's OK.

note that there exist some flags where the presence of the flag is semantically simpler than the absence of the flag! for example, a noundef function parameter can make a function considerably easier to understand. that's one of the things I disliked about the previous "file size" approach. could you please add some TODO/FIXME items regarding that sort of thing?

finally I agree that this should be unified with the quite similar code found elsewhere. I don't think that needs to block this pull request, but that's a displeasing kind of redundancy to have in our tool here.

note that there exist some flags where the presence of the flag is semantically simpler than the absence of the flag! for example, a noundef function parameter can make a function considerably easier to understand. that's one of the things I disliked about the previous "file size" approach. could you please add some TODO/FIXME items regarding that sort of thing?

IMO we should still be reducing away those attributes, if somebody submitted a test case I'd request irrelevant attributes to be removed

llvm/tools/llvm-reduce/ReducerWorkItem.cpp
607

a poison value is an undef value, isa<UndefValue>(V) is enough

608

I thought we wanted undef to be more expensive than 0?

644

do we want to add a flat cost to every instruction? (same with globals below)

note that there exist some flags where the presence of the flag is semantically simpler than the absence of the flag! for example, a noundef function parameter can make a function considerably easier to understand. that's one of the things I disliked about the previous "file size" approach. could you please add some TODO/FIXME items regarding that sort of thing?

IMO we should still be reducing away those attributes, if somebody submitted a test case I'd request irrelevant attributes to be removed

My struggle is I don't actually care about the IR on most failures I end up looking at, and want to minimize the MIR that comes out of it. Any annotations that decrease the emitted machine code are useful. One simple example is marking globals as internal/protected to avoid the GOT lookup

arsenm updated this revision to Diff 466613.Oct 10 2022, 2:05 PM

Count flags

aeubanks accepted this revision.Oct 11 2022, 12:48 PM

lgtm with one more question

llvm/tools/llvm-reduce/ReducerWorkItem.cpp
608

ping, maybe lump undef into return 3?

This revision is now accepted and ready to land.Oct 11 2022, 12:48 PM
arsenm added inline comments.Oct 11 2022, 1:02 PM
llvm/tools/llvm-reduce/ReducerWorkItem.cpp
608

Why would undef be treated as complex?

So far the actual scoring doesn't matter and we could probably do as well with a content agnostic hash that indicates some change occurred

aeubanks added inline comments.Oct 11 2022, 1:19 PM
llvm/tools/llvm-reduce/ReducerWorkItem.cpp
608

we'd rather reduce to 0 than undef

if we're going the route of hashing, then we should do that, but right now we're rerunning the reduction pipeline if the complexity has decreased. we try to reduce to 0 over undef, and if we do that but also make another reduction that decreases the complexity by one, the net complexity change will be zero and we won't rerun the pipeline.