Instruction::Switch: only first operand can be set to a non-constant value.
Instruction::InsertValue both the first and the second operand can be set to a non-constant value.
Instruction::Alloca return true for non-static allocation.
Details
Diff Detail
- Build Status
Buildable 7866 Build 7866: arc lint + arc unit
Event Timeline
alloca in particular is a little tricky. It's legal to hoist a constant operand (it doesn't change the semantics), but it's a bad idea: it turns a constant-size stack allocation into a variable-size stack allocation, which is much slower. Better to avoid messing with it. (This is similar to the way the current callers of canReplaceOperandWithVariable handle calls: it's technically legal, but not a good idea.)
Other changes look fine.
It would be nice to have a testcase for the InsertValue change, since it has an impact on SimplifyCFG even without D34921.
As we metioned in https://reviews.llvm.org/D34921. Should canReplaceOperandWithVariable only return false if isStaticAlloca is true for Instruction::Alloca here?
Hi, I changed the canReplaceOperandWithVariable but I did not add test for sink-common-code.ll. because I found in SimplifyCFG.cpp canSinkInstructions: there is a check:
for (auto *I : Insts) { // These instructions may change or break semantics if moved. if (isa<PHINode>(I) || I->isEHPad() || isa<AllocaInst>(I) || I->getType()->isTokenTy()) return false;
So it will always return false for AllocaInst.
For GVN sink, alloca instruction is also blacklisted in GVNSink::isInstructionBlacklisted.
So the logic in canReplaceOperandWithVariable will never be reached.