search for: isguaranteedtoexecut

...t licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case 'upper[j]' is not dominating exit block as its appearing > in second operand of logical AND operator. > > Prior to hoisting it check for condition in 'isGuaranteedToExecute' > and it decide not to hoist it. > > <File: LICM.cpp> > 666 bool LICM::isGuaranteedToExecute(Instruction &Inst) { > 667 > 668 // We have to check to make sure that the instruction dominates > all > 669 // of the exit blocks. If it doesn't, then ther...

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best,

...'t be too expensive. Maybe we can do it (relatively) cheaply:  - Remember the first throwing instruction in the header, instead of a    boolean, in LoopSafetyInfo  - In hoistRegion, remember if you've seen the first throwing    instruction yet  - Pass the above as a boolean parameter to isGuaranteedToExecute, and    instead of      if (Inst.getParent() == CurLoop->getHeader())        return !SafetyInfo->HeaderMayThrow;    do something like      if (Inst.getParent() == CurLoop->getHeader())        return IsBeforeThrowingInst; -- Sanjoy

...c1, label %exit.real, label %loop.outer exit.real: ; preds = %exit.inner %v.ph.lcssa = phi i32 [ %v.ph, %exit.inner ] ret i32 %v.ph.lcssa } where it unconditionally dereferences %x, effectively introducing UB if %x is not dereferenceable. The bug is in isGuaranteedToExecute. It assumes that if an instruction dominates all the loop exits then it will always be executed by the loop "on its way out". But there may never be a way out of the loop. -- Sanjoy

...ransforms/Scalar/LICM.cpp =================================================================== --- lib/Transforms/Scalar/LICM.cpp (revision 135415) +++ lib/Transforms/Scalar/LICM.cpp (working copy) @@ -151,6 +151,11 @@ /// bool isSafeToExecuteUnconditionally(Instruction &I); + /// isGuaranteedToExecute - Check that the instruction is guaranteed to + /// execute. + /// + bool isGuaranteedToExecute(Instruction &I); + /// pointerInvalidatedByLoop - Return true if the body of this loop may /// store into the memory location pointed to by V. /// @@ -577,6 +582,10 @@ if...

On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Piotr, > > On March 31, 2017 at 9:07:42 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > Hi all, > > I have a question about dereferenceable metadata on load instruction. I > > have a patch (https://reviews.llvm.org/D31539) for LICM that hoists >

There is PostDominatorTree for determining post-dominance. Even if A post-dominates B and B is executed, that doesn't guarantee that A will be executed. For example, there could be an infinite loop in-between. Strong post-dominance makes the stronger guarantee that there will be no infinite loop from B to A. Do we have anything in LLVM for determining strong post-dominance and in general for

...t;> >> - Remember the first throwing instruction in the header, instead of a >> boolean, in LoopSafetyInfo >> >> - In hoistRegion, remember if you've seen the first throwing >> instruction yet >> >> - Pass the above as a boolean parameter to isGuaranteedToExecute, and >> instead of >> if (Inst.getParent() == CurLoop->getHeader()) >> return !SafetyInfo->HeaderMayThrow; >> do something like >> if (Inst.getParent() == CurLoop->getHeader()) >> return IsBeforeThrowingInst; >> >&...

On 30 June 2015 at 14:30, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Interesting. Could you give an example why knowing a function will >>> halt is >>> essential for the heap-to-stack conversion? >>> >> >> The key situation you need to establish in order to do heap-to-stack >> conversion, is that you can see the calls to free (or realloc,

Hello, What follows is my attempt to describe how poison works. Let me know what you think. -- David # LLVM Poison Semantics Poison is an LLVM concept which exists solely to enable further optimization of LLVM IR. The exact behavior of poison has been, to say the least, confusing for users, researchers and engineers working with LLVM. This document hopes to clear up some of the confusion