search for: getunsignedrang

Dear all, Hi! I noticed an interesting situation when using getUnsignedRange and getSignedRange of SCEV for URem instruction. Here is an example with 2 IR instructions: %rem.lhs.trunc = trunc i32 %i15.082 to i8 --> getUnsignedRange --> [1,50) %rem81 = urem i8 %rem.lhs.trunc, 3 --> getUnsignedRange --> [-47,50) The problems are:...

...inkel at anl.gov> wrote: > > I would be scared to enable SCEV AA because it's not well tested > > This seems like a solvable problem. SCEV AA itself is something like 30 lines of non-boilerplate code, and essentially does one thing (calls getMinusSCEV in both directions and uses getUnsignedRange on the result). We should look it over. > > If SCEV AA itself is conservative, the worst that can happen is that it won't detect all cases it could, but we can extend it later. It seems to me that this piece of code was added as an experiment and never updated, but since it's alread...

...E. > > > > Suggestions? > > I would be scared to enable SCEV AA because it's not well tested This seems like a solvable problem. SCEV AA itself is something like 30 lines of non-boilerplate code, and essentially does one thing (calls getMinusSCEV in both directions and uses getUnsignedRange on the result). We should look it over. > and > updating SCEV across transforms can be problematic. LICM would > require another run of SCEV (bad for compile time). Why? 'Running' SE does not really do anything because we compute everything lazily. SE depends on DT, which I agre...

...nl.gov> wrote: > > I would be scared to enable SCEV AA because it's not well tested > > This seems like a solvable problem. SCEV AA itself is something like 30 > lines of non-boilerplate code, and essentially does one thing (calls > getMinusSCEV in both directions and uses getUnsignedRange on the result). > We should look it over. > If SCEV AA itself is conservative, the worst that can happen is that it won't detect all cases it could, but we can extend it later. It seems to me that this piece of code was added as an experiment and never updated, but since it's alread...

...,+,-1}<nuw>'! This means SCEV thinks `%idx.dec' will be poison in the very first iteration if %begin is ult 1. As an example on how this could blow up, if %begin was constant (or LLVM was got smarter about ranges someday and learned to handle non-constant ranges) in ScalarEvolution::getUnsignedRange, the following code could fire: if (const SCEVAddRecExpr *AddRec = dyn_cast<SCEVAddRecExpr>(S)) { // If there's no unsigned wrap, the value will never be less than its // initial value. if (AddRec->getNoWrapFlags(SCEV::FlagNUW)) if (const SCEVConstant *C = dyn_cas...

Hi, I am trying to understand the limitations of the current vectorizer, and came upon these test cases that fail to get vectorized. 1. loop1 below (note the increment by 2) fails to get vectorized because the access a[j+1] is considered to wrap around (the corresponding SCEV doesn't have nsw/nuw set) and hence isStridedPtr() in LoopAccessAnalysis.cpp return false. #define SIZE 100000 void

...er instructions. This will give ScalarEvolution, ValueTracking, etc. the benefit of analyzing these invariants in normalized form. The next step is introducing some way to use these invariants. I think that a natural place is to integrate these is with ScalarEvolution. We'd want functions like getUnsignedRange, isKnownNegative, isKnownPredicate, etc. to automatically take advantage of declared invariants. Internally, SE uses a function: /// isImpliedCondOperands - Test whether the condition described by Pred, /// LHS, and RHS is true whenever the condition described by Pred, FoundLHS, /// an...

On Oct 31, 2013, at 6:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > We currently generate suboptimal code for this loop: > > for (int i = 1; i < LEN; i++) { > a[i] = a[0] + b[i]; > } > > The largest problem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at

Hello, We currently generate suboptimal code for this loop: for (int i = 1; i < LEN; i++) { a[i] = a[0] + b[i]; } The largest problem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at 1 in this loop). While we can probably fix the vectorizer to handle this, I don't think that is the right place for