search for: addrecexprs

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

Hi Preston, On Fri, May 4, 2012 at 9:12 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > which produces > > %arrayidx24 = getelementptr inbounds [100 x [100 x i64]]* %A, i64 > %arrayidx21.sum, i64 %add1411, i64 %add > store i64 0, i64* %arrayidx24, align 8 > {{{(5 + ((3 + %n) * %n)),+,(2 * %n * %n)}<%for.cond1.preheader>,+,(4 *

The loop vectorizer seems to be not able to vectorize the following code: void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) { const std::uint64_t inner = 4; for (std::uint64_t i = start ; i < end ; ++i ) { const std::uint64_t ir0 = ( (i/inner) * 2 + 0 ) * inner + i%4; const std::uint64_t ir1 = ( (i/inner)

Hello, I'm studying how the SCEV analyzis works and how to use it and I could not create an example where the SCEV analyzis identifies an expression as "SCEVAddRecExpr". Aren't the expressions below the kind of pattern that should be represented as a "AddRecExpr" ? SCEV: (1 + (2 * %3) or SCEV: (%1 + (2 * %3) or SCEV: (%1 + (%2 * %3) In my experiments they are

Is there any chance of replacing/extending the GEP instruction? As noted in the GEP FAQ, GEPs don't support variable-length arrays; when the front ends have to support VLAs, they linearize the subscript expressions, throwing away information. The FAQ suggests that folks interested in writing an analysis that understands array indices (I'm thinking of dependence analysis) should be

Hi Frank, The access pattern to arrays a and b is non-linear. Unrolled loops are usually handled by the SLP-vectorizer. Are ir0 and ir1 consecutive for all values for i ? Thanks, Nadav On Oct 30, 2013, at 9:05 AM, Frank Winter <fwinter at jlab.org> wrote: > The loop vectorizer seems to be not able to vectorize the following code: > > void bar(std::uint64_t start,

...hrough the public interface, which would pollute all analysis after that point with those unwanted flags. I don't know if any callers actually do this but I could see it being useful for looking at hypothetical cases. To some degree mutation of wrapping flags is part of the design, because SCEVAddRecExprs are explicitly const_casted to add flags in multiple places so that they can be found again later. But that might not be quite so harmful because they at least contain a Loop as a contextual cue that prevents some leaking. So, my real question is does anyone know what the contract with ScalarEvolu...

Hi Sebastian, Recently, I found the "Polly - Calculate dependences" pass would lead to significant compile-time overhead when compiling some loop-intensive source code. Tobias told me you found similar problem as follows: http://llvm.org/bugs/show_bug.cgi?id=14240 My evaluation shows that "Polly - Calculate dependences" pass consumes 96.4% of total compile-time overhead

...which would pollute all analysis after that > point with those unwanted flags. I don't know if any callers actually > do this but I could see it being useful for looking at hypothetical > cases. > > To some degree mutation of wrapping flags is part of the design, > because SCEVAddRecExprs are explicitly const_casted to add flags in > multiple places so that they can be found again later. But that might > not be quite so harmful because they at least contain a Loop as a > contextual cue that prevents some leaking. > > So, my real question is does anyone know what the c...

On 07/28/2013 06:52 AM, Star Tan wrote: > Hi Tobias, > > I tried to investigated the problem related to ScopInfo, but I need your > help on handling some problems about ISL and SCEV. I copied the list as the discussion may be helpful for others. @Sven, no need to read all. Just search for your name. [..] >>The interesting observation is, that Polly introduces three parameters

Well, they are not directly consecutive. They are consecutive with a constant offset or stride: ir1 = ir0 + 4 If I rewrite the function in this form void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) { const std::uint64_t inner = 4; for (std::uint64_t i = start ; i < end ; ++i ) { const std::uint64_t ir0 = (

Verifying function running passes ... LV: Checking a loop in "bar" LV: Found a loop: L0 LV: Found an induction variable. LV: We need to do 0 pointer comparisons. LV: Checking memory dependencies LV: Bad stride - Not an AddRecExpr pointer %13 = getelementptr float* %arg2, i32 %1 SCEV: ((4 * (sext i32 {(256 + %arg0),+,1}<nw><%L0> to i64)) + %arg2) LV: Src Scev: {((4 * (sext

Hi Tobias and Sven, Thanks for your discussion and suggestion. @Sven: ISL actually allows users to have different identifiers with the same name. The problem that we have discussed is caused by incorrect usage of isl_space in Polly, so please do not worry about ISL library. You can skip the following information related to Polly implementation. @Tobias and Polly developers: I have attached

On 07/25/2013 09:01 PM, Star Tan wrote: > Hi Sebastian, > > > Recently, I found the "Polly - Calculate dependences" pass would lead to significant compile-time overhead when compiling some loop-intensive source code. Tobias told me you found similar problem as follows: > http://llvm.org/bugs/show_bug.cgi?id=14240 > > > My evaluation shows that "Polly -

Frank, It looks like the loop vectorizer is unable to tell that the two stores in your code never overlap. This is probably because of the sign-extend in your code. Can you extend the indices to 64bit ? Thanks, Nadav On Oct 28, 2013, at 1:38 PM, Frank Winter <fwinter at jlab.org> wrote: > Verifying function > running passes ... > LV: Checking a loop in "bar" > LV:

At 2013-07-26 14:14:51,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/25/2013 09:01 PM, Star Tan wrote: >> Hi Sebastian, >> >> >> Recently, I found the "Polly - Calculate dependences" pass would lead to significant compile-time overhead when compiling some loop-intensive source code. Tobias told me you found similar problem as follows:

On Nov 13, 2013, at 3:39 AM, Renato Golin <renato.golin at linaro.org> wrote: > Hi folks, > > I'm trying to analyse this piece of IR: > > for.body: ; preds = %for.body, %entry > %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] > %0 = shl nsw i64 %indvars.iv, 1 > %arrayidx = getelementptr inbounds

The debug messages are misleading. They should read “trying to vectorize a list of …”; The problem is that the SCEV analysis is unable to detect that C[ir0] and C[ir1] are consecutive. Is this loop from an important benchmark ? Thanks, Nadav On Oct 30, 2013, at 11:13 AM, Frank Winter <fwinter at jlab.org> wrote: > The SLP vectorizer apparently did something in the prologue of the

For void test0(unsigned short a, unsigned short * in, unsigned short * out) { for (unsigned short w = 1; w < a - 1; w++) //this will never overflow out[w] = in[w+7] * 2; } I think it will be sufficient to add a couple of new cases to ScalarEvolution::HowManyLessThans -- zext(A) ult zext(B) == A ult B sext(A) slt sext(B) == A slt B Currently it bails out if it sees a non-add

Hi, This is somewhat similar to the previous thread regarding missed vectorization opportunities (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084765.html), but maybe different enough to require a new thread. I'm seeing some missed vectorization opportunities in the loop vectorizer because SCEV is not able to fold sext/zext expressions into recurrence expressions (AddRecExpr). This