search for: flagnw

...flags if both the // outer mul and the inner addrec are guaranteed to have no overflow. // // No self-wrap cannot be guaranteed after changing the step size, but // will be inferred if either NUW or NSW is true. Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); // If all of the other operands were loop invariant, we are done. if (Ops.size() == 1) return NewRec; I understand that you can't assume it won't wrap around with the new stride, but I couldn't find an...

...// outer mul and the inner addrec are guaranteed to have no overflow. > // > // No self-wrap cannot be guaranteed after changing the step size, but > // will be inferred if either NUW or NSW is true. > Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); > const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); > > // If all of the other operands were loop invariant, we are done. > if (Ops.size() == 1) return NewRec; > > I understand that you can't assume it won't wrap around with the new stri...

On 16 November 2013 06:56, Andrew Trick <atrick at apple.com> wrote: > - getMulExpr constructs a new AddRec with NSW: > > Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); > const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); > Hi Andrew, Thanks for looking at this. Clearing the flags here makes sense, but it's being too conservative. I'm thinking I'll need something like propagateSafeFlags(...) with knowledge of the loop indu...

...is piece of code inside getZeroExtendExpr()- // Cache knowledge of AR NW, which is propagated to this // AddRec. Negative step causes unsigned wrap, but it // still can't self-wrap. const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW); // Return the expression with the addrec on the outside. return getAddRecExpr( getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, Depth + 1), getSignExtendExpr(Step, Ty, Dept...

...bounds GEP, then we know the address // space cannot be wrapped around. We cannot make any guarantee // about signed or unsigned overflow because pointers are // unsigned but we may have a negative index from the base // pointer. if (GEP->isInBounds()) Flags = setFlags(Flags, SCEV::FlagNW); } //-------------------------------------------------------------------------// Is there any reason to not check also Sub operator in a similar way to the Add operator? //-------------------------------------------------------------------------// if (const SubOperator *OBO = dyn_cast<SubOper...

...AddExpr(LIOps, Flags); > > // Build the new addrec. Propagate the NUW and NSW flags if both the > // outer add and the inner addrec are guaranteed to have no > overflow. > // Always propagate NW. > Flags = AddRec->getNoWrapFlags(setFlags(Flags, SCEV::FlagNW)); > const SCEV *NewRec = getAddRecExpr(AddRecOps, AddRecLoop, Flags); > > // If all of the other operands were loop invariant, we are done. > if (Ops.size() == 1) return NewRec; > > Thanks! > -- Sanjoy > -------------- next part -------------- An HTML a...

...> > > // Cache knowledge of AR NW, which is propagated to this > > // AddRec. Negative step causes unsigned wrap, but it > > // still can't self-wrap. > > const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW); > > // Return the expression with the addrec on the outside. > > return getAddRecExpr( > > getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, > > Depth + 1), > &gt...

​Hi, Would you be able to kindly check and assist with the IndVarSimplify / SCEV problem I got in the latest LLVM, please? Sometimes IndVarSimplify may not eliminate narrow IV's when there actually exists such a possibility. This may affect other LLVM passes and result in inefficient code. The reproducing test 'indvar_test.cpp' is attached. The problem is with the second

...the address > // space cannot be wrapped around. We cannot make any guarantee > // about signed or unsigned overflow because pointers are > // unsigned but we may have a negative index from the base > // pointer. > if (GEP->isInBounds()) > Flags = setFlags(Flags, SCEV::FlagNW); > } > //-------------------------------------------------------------------------// > > Is there any reason to not check also Sub operator in a similar way to the Add > operator? > > //-------------------------------------------------------------------------// > if (cons...

...13, at 4:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > >> On 16 November 2013 06:56, Andrew Trick <atrick at apple.com> wrote: >> - getMulExpr constructs a new AddRec with NSW: >> >> Flags = AddRec->getNoWrapFlags(clearFlags(Flags, SCEV::FlagNW)); >> const SCEV *NewRec = getAddRecExpr(NewOps, AddRecLoop, Flags); > > Hi Andrew, > > Thanks for looking at this. > > Clearing the flags here makes sense, but it's being too conservative. I'm thinking I'll need something like propagateSafeFlags(...) wi...

...ce cannot be wrapped around. We cannot make any guarantee > > // about signed or unsigned overflow because pointers are > > // unsigned but we may have a negative index from the base > > // pointer. > > if (GEP->isInBounds()) > > Flags = setFlags(Flags, SCEV::FlagNW); > > } > > //-------------------------------------------------------------------------// > > > > Is there any reason to not check also Sub operator in a similar way > > to the Add > > operator? > > > > //--------------------------------------------...

...> > // Cache knowledge of AR NW, which is propagated to this > > // AddRec. Negative step causes unsigned wrap, but it > > // still can't self-wrap. > > const_cast<SCEVAddRecExpr > *>(AR)->setNoWrapFlags(SCEV::FlagNW); > > // Return the expression with the addrec on the outside. > > return getAddRecExpr( > > getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, > > Depth + 1), > &gt...