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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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). |
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 |
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. { |
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. |
Perhaps add a debug assert that this returns false always (for non-debug path, skip the simplification call for compile time).