search for: isinstructiontriviallydead

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write to memory will be dead code eliminated when the Inliner runs. Here is a...

for (BasicBlock::reverse_iterator I = BB.rbegin(), E = BB.rend(); I != E; ) { Instruction& inst = *I; ++I; <-- iterator should be advanced to the previous instruction // Happens to be an Instruction::SExt. // Works fine if I iterate forwards if (isInstructionTriviallyDead(&inst, TLI)) inst.eraseFromParent(); } Sorry for the inexperienced question, but I'm confused why this works when using a forward iterator, but fails in reverse. The iterator is moved off the current instruction so why would erasing the current instruction cause an error? --------...

...trivial read-only functions. Reid On Mon, May 10, 2010 at 8:28 PM, Thomas B. Jablin <tjablin at cs.princeton.edu> wrote: > Hi, > > All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. > > Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write to memory will be dead code eliminated when the Inliner runs. > > H...

...09800 return ReplaceInstUsesWith(LI, UndefValue::get(LI.getType())); 09801 } 09802 } First, what happens to the StoreInst? It looks like it is not attached anywhere. Second, I am seeing this happen in a block that is definitely reachable. Later on the null GEP is removed because it isInstructionTriviallyDead. But the undef store to null remains since the block is in fact reachable. This is obviously bad. So how does the undef store to null appear in the IR when it isn't attached anywhere and how can I get rid of it? What is this code trying to do, anyway?...

...imizes how much the actual SmallSetVector gets used, which saves a lot of time. static bool simplifyAndDCEInstruction(Instruction *I, SmallSetVector<Instruction *, 16> &WorkList, const DataLayout &DL) { if (isInstructionTriviallyDead(I, nullptr)) { // Loop over all of the values that the instruction uses. If there are // instructions being used, add them to the worklist, because they might // go dead after this one is removed. SmallVector<Instruction *, 8> Operands; for (User::op_iterator OI = I->op...

...09802 } > > First, what happens to the StoreInst? It looks like it is not attached > anywhere. The &LI argument causes it to be inserted before the load. > Second, I am seeing this happen in a block that is definitely reachable. > Later on the null GEP is removed because it isInstructionTriviallyDead. > But the undef store to null remains since the block is in fact reachable. > This is obviously bad. This xform doesn't have anything to do with block reachability. It effectively transforms "load from null pointer" into an unreachable instruction. Load from null pointer i...