search for: scevunknown

...f I can post the reduced *.ll (2k+ lines) to the list. Let me try my best to describe this problem without *.ll. Let me start from 5k feet high. ================================== The relevant aspect of SCEV regarding to the problem are: a1) SCEV is *NOT* self-contained. At least SCEVUnknown points to an llvm::Instruction. a2) SCEV must be in sync with IR. One way to sync them is to delete invalidate SCEV, and force SE to recompute based on most recent IR. SCEVUnknonw is invalidated if its corresponding llvm::Instruction is deleted. However, it dose not inv...

...ng about this I looked again into ScalarEvolution. > >> > >> To analyze a load, you would do: > >> > >> LoadInst *Load = ... > >> Value *Pointer = Load->getPointer(); > >> const SCEV *PointerSCEV = SE->getSCEV(Pointer); > >> const SCEVUnknown *PointerBase = > >> dyn_cast<SCEVUnknown>(SE->getPointerBase(PointerSCEV)); > >> > >> if (!PointerBase) > >> return 'Analysis failed' > >> > >> const Value *BaseValue = PointerBase->getValue(); > >> > >&gt...

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops (usually programmers do not write non-nature loops), it doesn't really need to evolute some conditional-variables. but, LLVM uses SCEV for otherall loop-analysis...

...bout this I >>>> looked again into ScalarEvolution. >>>> >>>> To analyze a load, you would do: >>>> >>>> LoadInst *Load = ... Value *Pointer = Load->getPointer(); const >>>> SCEV *PointerSCEV = SE->getSCEV(Pointer); const SCEVUnknown >>>> *PointerBase = >>>> dyn_cast<SCEVUnknown>(SE->getPointerBase(PointerSCEV)); >>>> >>>> if (!PointerBase) return 'Analysis failed' >>>> >>>> const Value *BaseValue = PointerBase->getValue(); >>>&...

...e to make NULL work like I want, but it would be > simpler if something was already defined. I'm wondering about > SCEV::Unknown. The documentation suggests I could perhaps use it for > a "bottom" value. > > Think it would work? The documentation definitely says that SCEVUnknown is the "bottom" value. But the semantics you have listed here are different from how SCEVUnknown works. For example, B = A + Unknown is not Unknown, but it is in fact an add expression. If B is an operand for another add expression C, then it can be flattened so that A participates in any...

I'd like a value, call it Bottom, such that SE->getAddExpr(Bottom, X) => Bottom SE->getMulExpr(Bottom, X,) => Bottom isKnownPredicate(any, Bottom, X) => false etc. I can write code to make NULL work like I want, but it would be simpler if something was already defined. I'm wondering about SCEV::Unknown. The documentation suggests I could perhaps use it for a

Tobias Grosser wrote: > You create a map from the old_loop to a symbolic expression. What type would > this symbolic expression have? Would it be a SCEVExpr? evaluateAtIteration takes a scev, so apply will take a scev, or a map (loop->scev). You can always build a ScevUnknown from an SSA name and use that in the apply. > At the moment, we calculate at the beginning of each > polly statement (a basic block) a value for each virtual induction > variable of the original loops. For your example we get something like > this. > > new_bb: > new_iv_1...

...sounds great; I'll have to look at that. > > Talking about this I looked again into ScalarEvolution. > > To analyze a load, you would do: > > LoadInst *Load = ... > Value *Pointer = Load->getPointer(); > const SCEV *PointerSCEV = SE->getSCEV(Pointer); > const SCEVUnknown *PointerBase = > dyn_cast<SCEVUnknown>(SE->getPointerBase(PointerSCEV)); > > if (!PointerBase) > return 'Analysis failed' > > const Value *BaseValue = PointerBase->getValue(); > > You get the offset between two load addresses with SE->getMinusSC...

...M, Hal Finkel wrote: >> Talking about this I looked again into ScalarEvolution. >> >> To analyze a load, you would do: >> >> LoadInst *Load = ... >> Value *Pointer = Load->getPointer(); >> const SCEV *PointerSCEV = SE->getSCEV(Pointer); >> const SCEVUnknown *PointerBase = >> dyn_cast<SCEVUnknown>(SE->getPointerBase(PointerSCEV)); >> >> if (!PointerBase) >> return 'Analysis failed' >> >> const Value *BaseValue = PointerBase->getValue(); >> >> You get the offset between two load ad...

...: ( %i + %r54 + %r59) ( %r54 + %r59 + %i) As a result, passes like LoopStrengthReduce which use addresses of SCEVs as keys in std::map end up using different entries for these. The obvious solution would be to sort the values. Many SCEV types could be ordered in reasonable ways, though for SCEVUnknown it would require an ordering for Value objects, and I don't really want this to get complicated. I'm considering just using getValueID() as a primary sort and then using the value name to sort values of the same kind. Using names is straight-forward, but it could lead to spruious reordering...

...WithConstantOffset(). > > Thanks! That sounds great; I'll have to look at that. Talking about this I looked again into ScalarEvolution. To analyze a load, you would do: LoadInst *Load = ... Value *Pointer = Load->getPointer(); const SCEV *PointerSCEV = SE->getSCEV(Pointer); const SCEVUnknown *PointerBase = dyn_cast<SCEVUnknown>(SE->getPointerBase(PointerSCEV)); if (!PointerBase) return 'Analysis failed' const Value *BaseValue = PointerBase->getValue(); You get the offset between two load addresses with SE->getMinusSCEV(). The size of an element is SE->...

...ut it would be > > simpler if something was already defined. I'm wondering about > > SCEV::Unknown. The documentation suggests I could perhaps use it for > > a "bottom" value. > > > > Think it would work? > > The documentation definitely says that SCEVUnknown is the "bottom" > value. But the semantics you have listed here are different from how > SCEVUnknown works. For example, B = A + Unknown is not Unknown, but it > is in fact an add expression. If B is an operand for another add > expression C, then it can be flattened so that A...

...check if the target wants to ignore these? I suppose this could apply to other target with hardware loop support. 2. C.SetupCost What it the motivation behind this code? // Rough heuristic; favor registers which don't require extra setup // instructions in the preheader. if (!isa<SCEVUnknown>(Reg) && !isa<SCEVConstant>(Reg) && !(isa<SCEVAddRecExpr>(Reg) && (isa<SCEVUnknown>(cast<SCEVAddRecExpr>(Reg)->getStart()) || isa<SCEVConstant>(cast<SCEVAddRecExpr>(Reg)->getStart())))) ++C.Se...

...to trigger that > > Hi Marcello, > > the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression > or if the analysis would be to complicated. I am currently > not sure if this may actually happen when calling getSCEV(), because > getSCEV() could just return a SCEVUnknown referencing the Value itself. > Maybe SCEVCouldNotCompute is just generated by functions like > SE->getBackedgeTakenCount()? > > In case you cannot generate a test case that yields to this, I don't think > there is a need to try more. Even without such a test case the patch sh...

...EVAddExpr>(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); > + } else if (const SCEVUnknown *U = dyn_cast<SCEVUnknown>(S)) { > + // This is a leaf node. > + return U->getValue(); > + } > + // No Identified object found. > + return 0; > +} As remarked earlier, I believ this can be replaced by getPointerOperand(). > bool ScopDetection::isValidMemor...

...l::desc("Allow non affine access functions for arrays"), > + cl::Hidden, cl::init(false)); > + > //===----------------------------------------------------------------------===// > // Statistics. > > @@ -236,7 +241,9 @@ > BasePointer = dyn_cast<SCEVUnknown>(SE->getPointerBase(AccessFunction)); > > if (!BasePointer) > + { > INVALID(AffFunc, "No base pointer"); > + } This change is unneeded and unrelated. > > BaseValue = BasePointer->getValue(); > > @@ -245,8 +252,9 @@ > > AccessF...

...or a while but I wasn't able to trigger that Hi Marcello, the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression or if the analysis would be to complicated. I am currently not sure if this may actually happen when calling getSCEV(), because getSCEV() could just return a SCEVUnknown referencing the Value itself. Maybe SCEVCouldNotCompute is just generated by functions like SE->getBackedgeTakenCount()? In case you cannot generate a test case that yields to this, I don't think there is a need to try more. Even without such a test case the patch should be OK. Cheers To...

...t;> Hi Marcello, >> >> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an expression >> or if the analysis would be to complicated. I am currently >> not sure if this may actually happen when calling getSCEV(), because >> getSCEV() could just return a SCEVUnknown referencing the Value itself. >> Maybe SCEVCouldNotCompute is just generated by functions like >> SE->getBackedgeTakenCount()? >> >> In case you cannot generate a test case that yields to this, I don't think >> there is a need to try more. Even without such a te...

...+    // 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); >> +  } else if (const SCEVUnknown *U = dyn_cast<SCEVUnknown>(S)) { >> +    // This is a leaf node. >> +    return U->getValue(); >> +  } >> +  // No Identified object found. >> +  return 0; >> +} > > As remarked earlier, I believ this can be replaced by getPointerOperand(). > &g...

On Tue, 2011-11-08 at 20:24 +0100, Tobias Grosser wrote: > On 11/08/2011 03:36 PM, Hal Finkel wrote: > > On Tue, 2011-11-08 at 12:12 +0100, Tobias Grosser wrote: > >> On 11/08/2011 11:45 AM, Hal Finkel wrote: > >>> I've attached the latest version of my autovectorization patch. > >>> > >>> Working through the test suite has proved to be a