search for: scevaddexpr

...gt; const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(SCEVNode); > 'var' is of type float pointer (float*). > Without 'sext' it works, but I'm wondering why it not working in above case. > I'm not sure, is such casting allowed ? It looks like your node is a SCEVAddExpr whose LHS is "(4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw>" and RHS is "%var", instead of a SCEVAddRecExpr. Perhaps if the sext weren't there SCEV might simplify the whole thing to a single SCEVAddRecExpr. Can you cast your node to a SCEVAddExpr, then dy...

Hi, I'm trying to cast one of the SCEV node to "SCEVAddRecExpr". Every time cast return NULL, and I'm unable to do this. SCEV Node: ((4 * (sext i32 {2,+,2}<%for.body4> to i64))<nsw> + %var)<nsw> Casting: const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(SCEVNode); 'var' is of type float pointer (float*). Without 'sext' it works, but

...xpr *AR = dyn_cast<SCEVAddRecExpr>(SCEVNode); >> 'var' is of type float pointer (float*). >> Without 'sext' it works, but I'm wondering why it not working in above case. >> I'm not sure, is such casting allowed ? > > It looks like your node is a SCEVAddExpr whose LHS is "(4 * (sext i32 > {2,+,2}<%for.body4> to i64))<nsw>" and RHS is "%var", instead of a > SCEVAddRecExpr. Perhaps if the sext weren't there SCEV might simplify > the whole thing to a single SCEVAddRecExpr. > > Can you cast your node to a...

...asAnalysis.cpp:64) 2. ScalarEvolution::getMinusSCEV will boil down into ScalarEvolution::getAddExpr. On line 2383 of lib/Analysis/ScalarEvolution.cpp, GroupByComplexity is invoked. 3. CompareSCEVComplexity is eventually called to give a partial order between two SCEV expression. 4. If there are two SCEVAddExpr that are located in different loops which don’t have any hierarchical relation, just like pointers in line 6 and line 10 in the input program(i.e. ptr_test.c), it will violate the assertion in line 705 in lib/Analysis/ScalarEvolution.cpp. The point is that the assertion in line 705 doesn’t make s...

...to mark expressions (like we have `nsw` and `nuw` for `sext` and `zext`) which we can distribute `sitofp` and `uitofp` over? Same questions for `fptosi` and `fptoui`. - How will you partition the logic between floating and integer expressions in SCEV-land? Will you have, say, `SCEVAddExpr` do different things based on type, or will you split it into `SCEVIAddExpr` and `SCEVFAddExpr`? [0] * There are likely to be similarities too -- e.g. the "inductive" or "control flow" aspect of `SCEVAddRecExpr` is likely to be common between floating po...

...e. A completely general approach to IV analysis is ScalarEvolution. You can query the expression for a loop header phi using ScalarEvolution::getSCEV. If it returns SCEVAddRecExpr with getLoop() == ThisLoop, then you've found an IV. You can build a new IV by replacing the "step" with SCEVAddExpr(1 + OrigStep). To materialize it in IR, you need to use a SCEVExpander. ...probably more complicated than you need. -Andy > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Malveeka Tewari > Sent: Thursday, May 05, 2011 14:51 > To: ll...

...ction::GetBaseValue(const SCEV *S) const { > + if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S)) { > + // In an addrec, assume that the base will be in the start, rather > + // than the step. > + return GetBaseValue(AR->getStart()); > + } else if (const SCEVAddExpr *A = dyn_cast<SCEVAddExpr>(S)) { > + // If there's a pointer operand, it'll be sorted at the end of the list. > + const SCEV *Last = A->getOperand(A->getNumOperands()-1); > + if (Last->getType()->isPointerTy()) > + return GetBaseValue(Last); >...

...t;SCEVAddRecExpr>(SCEVNode); >>> 'var' is of type float pointer (float*). >>> Without 'sext' it works, but I'm wondering why it not working in above case. >>> I'm not sure, is such casting allowed ? >> >> It looks like your node is a SCEVAddExpr whose LHS is "(4 * (sext i32 >> {2,+,2}<%for.body4> to i64))<nsw>" and RHS is "%var", instead of a >> SCEVAddRecExpr. Perhaps if the sext weren't there SCEV might simplify >> the whole thing to a single SCEVAddRecExpr. >> >> Can yo...

...on::getMinusSCEV will boil down into > ScalarEvolution::getAddExpr. On line 2383 of > lib/Analysis/ScalarEvolution.cpp, GroupByComplexity is invoked. > > 3. CompareSCEVComplexity is eventually called to give a partial order > between two SCEV expression. > > 4. If there are two SCEVAddExpr that are located in different loops > which don’t have any hierarchical relation, just like pointers in line 6 > and line 10 in the input program(i.e. ptr_test.c), it will violate the > assertion in line 705 in lib/Analysis/ScalarEvolution.cpp. > > > > The point is that the ass...

...const SCEV *S)  const { >> +  if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S)) { >> +    // In an addrec, assume that the base will be in the start, rather >> +    // than the step. >> +    return GetBaseValue(AR->getStart()); >> +  } else if (const SCEVAddExpr *A = dyn_cast<SCEVAddExpr>(S)) { >> +    // If there's a pointer operand, it'll be sorted at the end of the >> list. >> +    const SCEV *Last = A->getOperand(A->getNumOperands()-1); >> +    if (Last->getType()->isPointerTy()) >> +      return...

...it did, I probably would not have written my e-mail), but applying it only to the 'address computation' itself. On the other hand, maybe that violates SCEV's general philosophy of being control-flow independent (maybe the logic that prohibits us from applying an add's nsw flag to an SCEVAddExpr should prohibit this as well). > > As an aside, you could still prove no-self-wrap for this recurrence. > If the base of the GEP is an NW recurrence (note that NSW or NUW > implies NW), the GEP itself is inbounds, and the GEP simplifies to a > recurrences, then I think you can infe...

Mmm I found out a very strange behavior (to me) of the SCEV analysis of the loop bound of the external loop I posted. When in ScopDetection it gets the SCEV of the external loop bound in the "isValidLoop()" function with: const SCEV *LoopCount = SE->getBackedgeTakenCount(L); It returns a SCEVCouldNotCompute, but if I change the "if" block inside the loop from: if

Malveeka, You can use the LoopInfo analysis to find the induction variable. http://llvm.org/docs/doxygen/html/classllvm_1_1Loop.html#a72bbf45d2e00971f56bf8cfe4e1df01c Cheers, Nadav From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Malveeka Tewari Sent: Thursday, May 05, 2011 14:51 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Loop transformations

Hi I am trying to write up a transformation for the following code where instead of incrementing the loop variable by 1, I increment it by 2 ie. for (i=0; i < THRES; *i++*) { //do something } gets transformed to for (i=0; i < THRES; *i+=2*) { //do something } I am thinking of transforming the llvm bit-code in the following way. Iterate over the function for the original code till I

...eturn zext; +} + /// getTruncateOrZeroExtend - Return a SCEV corresponding to a conversion of the /// input value to the specified type. If the type must be extended, it is zero /// extended. @@ -3029,13 +3040,22 @@ const SCEV *ScalarEvolution::createNodeForPHI(PHINode *PN) { if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(BEValue)) { // If there is a single occurrence of the symbolic value, replace it // with a recurrence. + const SCEVZeroExtendExpr *zext = 0; + const SCEVTruncateExpr *trunc = 0; unsigned FoundIndex = Add->getNu...

...------------------- opt: $SRC/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:2165: const llvm::SCEV *llvm::ScalarEvolution::getAddExpr(SmallVectorImpl<const llvm::SCEV *> &, SCEV::NoWrapFlags, unsigned int): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "SCEVAddExpr operand types don't match!"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: $Tools/bin/opt -O3 test.ll -o out.ll llvm::ScalarEvolution::getAddExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&,...

Hi, I'm working now on extending SCEV Analysis and adding FP support. At the beginning, I want to vectorize this loop: float fp_inc; float x = init; for (int i=0;i<N;i++){ A[i] = x; x += fp_inc; // Loop invariant variable or constant } In this loop "x" is a FP induction variable. But it is not the "primary" induction and loop trip count is still depends

On Oct 31, 2013, at 1:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Andy, et al., > > If I start with C code like this: > > void foo(long k, int * restrict a, int * restrict b, int * restrict c) { > if (k > 0) { > for (int i = 0; i < 2047; i++) { > a[i] = a[i + k] + b[i] * c[i]; > } > } > } > > Clang -O3 will produce code like

...ofp should be 2 different operations. Same questions for `fptosi` and `fptoui`. [Demikhovsky, Elena] the same answer as above, because I don’t want to combine these operations - How will you partition the logic between floating and integer expressions in SCEV-land? Will you have, say, `SCEVAddExpr` do different things based on type, or will you split it into `SCEVIAddExpr` and `SCEVFAddExpr`? [0] [Demikhovsky, Elena] Yes, I’m introducing SCEVFAddExpr and SCEVFMulExpr - (start + delta * sitofp(i)) * There are likely to be similarities too -- e.g. the "inductive"...

Andy, et al., If I start with C code like this: void foo(long k, int * restrict a, int * restrict b, int * restrict c) { if (k > 0) { for (int i = 0; i < 2047; i++) { a[i] = a[i + k] + b[i] * c[i]; } } } Clang -O3 will produce code like this: entry: %cmp = icmp sgt i64 %k, 0 br i1 %cmp, label %for.body.preheader, label %if.end for.body.preheader: br label