search for: constantfoldterminator

I'm looking into some missed optimizations where CodeGenPrepare seems to leave trivially dead instructions lying around. This happens because CodeGenPrepare::runOnFunction calls ConstantFoldTerminator which folds a "br i1 false" into an unconditional branch and calls BasicBlock::removePredecessor which calls PHINode::removeIncomingValue. Each incoming value that is removed from a phi node might be dead now, but nothing deletes them. Is there any way this could be improved? Could PHINo...

...ock, so those two should do the work. In TailRecursionElimination.cpp, there's logic which uses a "10-fold increase" heuristic. It would be nice if that code were factored out into a utility routine so that the profiling heuristics are more centralized. > - bool Folded = ConstantFoldTerminator(I->getParent()); > + bool Folded = ConstantFoldTerminator(I->getParent(), this); I don't see any corresponding changes to the definition of ConstantFoldTerminator. Are there files missing from the patch? Dan On Dec 3, 2009, at 9:56 AM, Andreas Neustifter wrote: > Hi all,...

Hi all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text

...where the code generated after > > CodeGenPrepare pass has "br i1 false .." with both true and false > > conditions preserved and this propagates further and remains the same > > in the final assembly code/executable. > > > > In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which > > handles the br i1 false condition) is called only once and if after > > the transformation of code by ConstantFoldTerminator() and > > DeleteDeadBlock() we end up with code like "br i1 false", there is no > > further opportunity to clean them up. So call...

...istic. It would be nice if that code were > factored out into a utility routine so that the profiling > heuristics are more centralized. Agreed. Its hard to find all points that use such heuristics, since I couldn't find a common wording to grep on... >> - bool Folded = ConstantFoldTerminator(I->getParent()); >> + bool Folded = ConstantFoldTerminator(I->getParent(), this); > > I don't see any corresponding changes to the definition of > ConstantFoldTerminator. Are there files missing from the patch? As mentioned earlier, I was more interested in the...

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the transformation of code by ConstantFoldTerminator() and DeleteDeadBlock() we end up with code like "br i1 false", there is no further opportunity to clean them up. So calling this code under (!DisableBranchOpts)...

...cessor block pred->replaceAllUsesWith(succ); // Simplify conditional branches for (Value::use_iterator ui = succ->use_begin(); ui != succ->use_end(); ++ui) { Instruction *inst = dyn_cast<Instruction>(*ui); if (inst) ConstantFoldTerminator(inst->getParent()); } // Clean out dead PHI nodes DeleteDeadPHIs(succ); return true; } On 02/01/2011 04:57 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > >> On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: >> >>> I...

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm

...1a _sigtramp + 26 3 libsystem_platform.dylib 0x00007fff58cdc578 _sigtramp + 3247130232 4 libLLVMSupport.3.7.0.dylib 0x00000001087ea5e6 abort + 22 5 libLLVMSupport.3.7.0.dylib 0x00000001087ea5c1 __assert_rtn + 81 6 libLLVMTransformUtils.3.7.0.dylib 0x0000000108870236 llvm::ConstantFoldTerminator(llvm::BasicBlock*, bool, llvm::TargetLibraryInfo const*) + 3782 7 libLLVMScalarOpts.3.7.0.dylib 0x000000010867905b (anonymous namespace)::IPSCCP::runOnModule(llvm::Module&) + 6043 8 libLLVMCore.3.7.0.dylib 0x0000000108131aa3 llvm::legacy::PassManagerImpl::run(llvm::Module&)...

Hi, On Mon, May 1, 2017 at 8:47 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Today, the IR requires that if you have multiple edges from A to B >> (typically with a switch) any phi nodes in B must have an equal number of >> entries for A, but that all of them must have the same value. > >> This seems rather annoying.... >> 1) It

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Katya Romanova" <Katya_Romanova at playstation.sony.com>, "Nick Lewycky" <nlewycky at google.com> > Cc: llvmdev at cs.uiuc.edu, "Philip Reames" <listmail at philipreames.com>, "Hal Finkel" <hfinkel at anl.gov>,