This is an archive of the discontinued LLVM Phabricator instance.

[InlineCost] Remove visitUnaryInstruction()
ClosedPublic

Authored by aeubanks on Apr 29 2021, 2:53 PM.

Details

Summary

The simplifyInstruction() in visitUnaryInstruction() does not trigger
for all of check-llvm. Looking at all delegates to UnaryInstruction in
InstVisitor, the only instructions that either don't have a visitor in
CallAnalyzer, or redirect to UnaryInstruction, are VAArgInst and Alloca.
VAArgInst will never get simplified, and visitUnaryInstruction(Alloca)
would always return false anyway.

Diff Detail

Event Timeline

aeubanks created this revision.Apr 29 2021, 2:53 PM
aeubanks requested review of this revision.Apr 29 2021, 2:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2021, 2:53 PM
aeubanks updated this revision to Diff 341664.Apr 29 2021, 2:56 PM

disableSROA

lebedev.ri accepted this revision.Apr 29 2021, 3:36 PM

Not really familiar enough with this code to review, but sounds reasonable i guess.

This revision is now accepted and ready to land.Apr 29 2021, 3:36 PM
mtrofin added a reviewer: davidxl.
mtrofin accepted this revision.Apr 29 2021, 4:07 PM

reasonable simplification, my only concern is future evolution - like if a new IR instruction is introduced that would break the invariants you're describing; but I suppose we can cross that bridge when we get there.

This revision was landed with ongoing or failed builds.Apr 29 2021, 8:36 PM
This revision was automatically updated to reflect the committed changes.
davidxl added inline comments.Apr 29 2021, 8:49 PM
llvm/lib/Analysis/InlineCost.cpp
1372

Perhaps add a debug assert that this returns false always (for non-debug path, skip the simplification call for compile time).

aeubanks added inline comments.Apr 29 2021, 8:58 PM
llvm/lib/Analysis/InlineCost.cpp
1372

there isn't really a good place to put that assert, unless we want to define a CallAnalyzer::visitUnaryInstruction only in assert builds, which seems weird

davidxl added inline comments.Apr 29 2021, 9:08 PM
llvm/lib/Analysis/InlineCost.cpp
1372

The change to in visitAlloca is fine. To address the concern about future IR (mtrofin), how about keeping visitUnaryInstruction, but with a very simple body -- when it is called in the future, it will be caught and handled here.

{
assert(0);
return false;
}

aeubanks added inline comments.Apr 29 2021, 11:19 PM
llvm/lib/Analysis/InlineCost.cpp
1372

I'm not sure that it makes sense to special case the assert future instructions that are specifically unary instructions. What about future binary instructions? I'd say it makes more sense to have some assert in visitInstruction(), but I don't think there's some universal assert that can be applied to all potential future instructions.

lgtm

llvm/lib/Analysis/InlineCost.cpp
1372

Fair enough.