search for: isreachablefromentry

...gt;dominates(%b, %a). > > LLVM special cases "not reachable from entry", and says that no matter what, > #2 is true if %a is unreachable. > > The code is, IMHO, not even self-consistent > > > // Any unreachable use is dominated, even if Def == User. > if (!isReachableFromEntry(UseBB)) > return true; > > // Unreachable definitions don't dominate anything. > if (!isReachableFromEntry(DefBB)) > return false; > > > > Riddle me this: If unreachable definitions dominate nothing, how are > unreachable uses always dominated by th...

On 25 February 2015 at 10:58, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, Feb 25, 2015 at 6:26 AM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> > Maybe. >> > My view is the ideal is either no-unreachable code, or unreachable >> > blocks >> > only contain terminators. >> >> I am

...; LLVM special cases "not reachable from entry", and says that no matter what, >> #2 is true if %a is unreachable. >> >> The code is, IMHO, not even self-consistent >> >> >> // Any unreachable use is dominated, even if Def == User. >> if (!isReachableFromEntry(UseBB)) >> return true; >> >> // Unreachable definitions don't dominate anything. >> if (!isReachableFromEntry(DefBB)) >> return false; >> >> >> >> Riddle me this: If unreachable definitions dominate nothing, how are >...

Hello, I have code containing conditions and loops. Hence some BB execution are determined at run time depending on condition. Now I want to count only those BB that are always executed irrespective of condition result means reachable. and their execution is evident at compile time. How to do this? Please help Thank You Regards -------------- next part -------------- An HTML attachment was

When looking into https://llvm.org/bugs/show_bug.cgi?id=24866, I discovered that the root cause of the crash is that I was expecting every basic block to have a corresponding Node in the dominator tree. Apparently, the "while.end" basic block in the example does not have a Node in the Dominator Tree. Can anyone tell me if this is expected? If so, under what circumstances?

...re.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::eraseNode(llvm::BasicBlock*) in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o) ../../lib/libLLVMCore.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::isReachableFromEntry(llvm::BasicBlock const*) const in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o) ../../lib/libLLVMCore.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::print(llvm::raw_ostream&) const in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o...

Hi Hal, > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 such instructions are valid in unreachable basic blocks. > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when

Hello, After investigating PR14133, I've discovered that jump threading can output self-referential instructions: %inc.us = add nsw i32 %inc.us, 1 At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this instruction causes BBVectorize to hang. Should

----- 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>,