search for: getlooplatch

...d restoring it if necessary (assuming the loop didn't get removed and the metadata didn't get moved). However, the CFG simplifier pass also can optimize the loop latch and attached metadata away. As this is a function pass, I don't have access to the loop-specific functionality such as getLoopLatch to check for metadata. Any suggestions how to fix this? How would the parallel loop metadata discussed in here survive these CFG simplifications? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201303...

...a simple pass to print out Loop invariant instructions, using the Loop::isLoopInvariant(Instruction *I) function. it is giving me false value on instructions which should be loop invariant. the code i am using is: bool MyLoopPass::runOnLoop(Loop * L, LPPassManager &lpm){ BasicBlock* lat=L->getLoopLatch(); for (BasicBlock::iterator i = lat->begin(), e = lat->end(); i != e; ++i){ Instruction* hijk= i; if(L->isLoopInvariant(hijk)) errs() << "hurray " << *hijk << " is loop invariant\n"; else errs() << "bad luck\n"; } retur...

...d restoring it if necessary (assuming the loop didn't get removed and the metadata didn't get moved). However, the CFG simplifier pass also can optimize the loop latch and attached metadata away. As this is a function pass, I don't have access to the loop-specific functionality such as getLoopLatch to check for metadata. Any suggestions how to fix this? How would the parallel loop metadata discussed in here survive these CFG simplifications? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201303...

...). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader, NewPreHeader); > + } > + > // Preserve canonical loop form, which means Exit block should > // have only one predecessor. > SplitEdge(L->getLoopLatch(), Exit, this); Would it make sense to move the ProfileInfo updating code into SplitEdge? That way all users of SplitEdge would automatically do the right thing. Actually, SplitEdge just delegates to either SplitCriticalEdge or SplitBlock, so those two should do the work. In TailRecursionElimina...

.... It doesn't apply to memory operations, because hoisting them requires more analysis (e.g. mod-ref analysis for the rest of the loop). Please see the LICM pass to see how to do this. -Chris > > bool MyLoopPass::runOnLoop(Loop * L, LPPassManager &lpm){ > BasicBlock* lat=L->getLoopLatch(); > for (BasicBlock::iterator i = lat->begin(), e = lat->end(); i != e; ++i){ > Instruction* hijk= i; > if(L->isLoopInvariant(hijk)) > errs() << "hurray " << *hijk << " is loop invariant\n"; > else > errs() <&l...

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

...ptimizer bug: /Users/echeng/LLVM/llvm/Release/bin/opt -std-compile-opts -time-passes -info-output-file=/Volumes/Muggles/LLVM/llvm/projects/llvm-test/ MultiSource/Applications/ClamAV/Out\ put/clamscan.linked.bc.info Output/clamscan.linked.rbc -o Output/ clamscan.linked.bc -f Assertion failed: (getLoopLatch() && "Loop latch is missing"), function verifyLoop, file /Volumes/Muggles/LLVM/llvm/include/llvm/ Analysis/LoopInfo.h, line 517. I'll file a bug on this. Evan On Jan 10, 2008, at 2:41 AM, Török Edwin wrote: > Török Edwin wrote: >> Yes, I have uploaded the .tar...

Török Edwin wrote: > Yes, I have uploaded the .tar.gz here: > http://edwintorok.googlepages.com/ClamAV-srcflat.tar.gz > [inputs dir contains some symlink, place ClamAV dir in > llvm/projects/llvm-test/MultiSource/Applications to make > links point to right place] > > Hi, Because llvm bug #1730 got fixed, this testcase can run under with the JIT on x86-64 :). I have

...echeng/LLVM/llvm/Release/bin/opt -std-compile-opts -time-passes > -info-output-file=/Volumes/Muggles/LLVM/llvm/projects/llvm-test/ > MultiSource/Applications/ClamAV/Out\ > put/clamscan.linked.bc.info Output/clamscan.linked.rbc -o Output/ > clamscan.linked.bc -f > Assertion failed: (getLoopLatch() && "Loop latch is missing"), > function verifyLoop, file /Volumes/Muggles/LLVM/llvm/include/llvm/ > Analysis/LoopInfo.h, line 517. > > I'll file a bug on this. > > Evan > > > On Jan 10, 2008, at 2:41 AM, Török Edwin wrote: > >> Török Edwin...

...= getAnalysisIfAvailable<ProfileInfo>()) { >> + PI->splitEdge(OrigPreHeader, NewHeader, NewPreHeader); >> + } >> + >> // Preserve canonical loop form, which means Exit block should >> // have only one predecessor. >> SplitEdge(L->getLoopLatch(), Exit, this); > > Would it make sense to move the ProfileInfo updating code into > SplitEdge? That way all users of SplitEdge would automatically do > the right thing. Actually, SplitEdge just delegates to either > SplitCriticalEdge or SplitBlock, so those two should do the wo...

...} }; } char MyLoopPass::ID=0; INITIALIZE_PASS(MyLoopPass, "myLICM", "simple LICM pass", false, false); bool MyLoopPass::runOnLoop(Loop * L, LPPassManager &lpm){ //find loop pre-header BasicBlock* pre=L->getLoopPreheader(); curLoop=L; changed=false; BasicBlock* lat=L->getLoopLatch(); LI = &getAnalysis<LoopInfo>(); DT = &getAnalysis<DominatorTree>(); errs() <<"Loop Pre-Header:" << *pre; errs() <<"Loop Latch:" << *lat; for (BasicBlock::iterator i = lat->begin(), e = lat->end(); i != e; ++i){ Instruction...

...ns, because hoisting them > requires more analysis (e.g. mod-ref analysis for the rest of the loop). > Please see the LICM pass to see how to do this. > > -Chris > > > > > bool MyLoopPass::runOnLoop(Loop * L, LPPassManager &lpm){ > > BasicBlock* lat=L->getLoopLatch(); > > for (BasicBlock::iterator i = lat->begin(), e = lat->end(); i != e; > ++i){ > > Instruction* hijk= i; > > if(L->isLoopInvariant(hijk)) > > errs() << "hurray " << *hijk << " is loop invariant\...

...onicalize natural loops", "Canonicalize Induction Variables" or "Natural Loop Construction" such that the loops were represented in the same form. Still I do not find a one-to-one link between the loop condition, body and end, and the BasicBlocks returned by the getHeader, getLoopLatch etc. My next strategy would be to modify the front-end, clang, and attach metadata to indicate whether the BasicBlock is part of the condition or of the body of the loop. I would very much appreciate if you could suggest an easier way to differentiate between the parts of the loop. Thank you, Al...

i am getting seg fault on functions like I->eraseFromParent also. I'm assuming that the problem comes when i change the loop structure. On Thu, Nov 18, 2010 at 4:05 AM, Sreeraj a <writetosrj at gmail.com> wrote: > The funny thing is that i am manually able to hoist the Loop invariant > instruction to the basicBlock terminator, by editing the human readable form > and then

...n the vectorizer is explicit: // We only handle bottom-tested loops, i.e. loop in which the condition is // checked at the end of each iteration. With that we can assume that all // instructions in the loop are executed the same number of times. if (TheLoop->getExitingBlock() != TheLoop->getLoopLatch()) { ... -Hal > That seems both counter-intuitive and unlikely to be a useful goal. > We simply don't optimize volatile operations well in *any* part of > the optimizer, and I'm not sure why we need to start trying to fix > that. This seems like an irreparably broken benchm...

...t -std-compile-opts -time- >> passes >> -info-output-file=/Volumes/Muggles/LLVM/llvm/projects/llvm-test/ >> MultiSource/Applications/ClamAV/Out\ >> put/clamscan.linked.bc.info Output/clamscan.linked.rbc -o Output/ >> clamscan.linked.bc -f >> Assertion failed: (getLoopLatch() && "Loop latch is missing"), >> function verifyLoop, file /Volumes/Muggles/LLVM/llvm/include/llvm/ >> Analysis/LoopInfo.h, line 517. >> >> I'll file a bug on this. >> >> Evan >> >> >> On Jan 10, 2008, at 2:41 AM, Török Ed...

Hello . I'm trying to implement FunctionPass for detecting loops in llvm IR. How can I get <condition> for loop from llvm::Loop object.? Is there any example? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120723/85e7f2f9/attachment.html>

The funny thing is that i am manually able to hoist the Loop invariant instruction to the basicBlock terminator, by editing the human readable form and then using llvm-as to convert it into bytecode. On Thu, Nov 18, 2010 at 4:01 AM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 17, 2010, at 1:38 PM, Sreeraj a wrote: > > > Thanks Chris, > > > > I was

...loop in which the > > condition is > > > // checked at the end of each iteration. With that we can assume > > that > > all > > > // instructions in the loop are executed the same number of times. > > > if (TheLoop->getExitingBlock() != TheLoop->getLoopLatch()) { > > > ... > > Thanks for the detailed explanation. This makes much more sense why > we need to handle it. I think its much better to look at nested > loops of this form than anything to do with volatile -- the latter > is too prone to other random optimizations turni...

Dear all, Here's an updated version of the parallel loop metadata patch. It includes documentation for the new metadata types with a semantics description. -- Pekka -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel-loop-metadata.patch Type: text/x-patch Size: 12972 bytes Desc: not available URL: