search for: cannonicalization

...we could require that every target-specific selector supports and expands every operator and type even if they are not supported and may require many instructions to implement (in fact, this is the approach taken by the "simple" selectors). However, using a Legalize pass allows all of the cannonicalization patterns to be shared across targets which makes it very easy to optimize the cannonicalized code because it is still in the form of a DAG." * what is "the cannonicalization pattern"? sum of product? * "makes it very easy to optimize the cannonicalized code"? does it refer...

...Exits: 1023 %mul1 = mul nsw i64 %i.06, 7 --> {0,+,7}<%for.body> Exits: 7161 %arrayidx2 = getelementptr inbounds i32* %A, i64 %mul1 --> {%A,+,28}<%for.body> <== we want to see a nw flag here. Scev sometimes drops new flags for safety (cannonicalization can make them invalid if the same expression is used in different contexts) . See past discussions on this. We are thinking about doing something like described here: http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/67476 or in this thread:(http://lists.cs.uiuc.edu/pipermail/llvm-commi...

...y as possible. > Restructuring expr this expr is also able to reduce the critical path even if no sub-expr is > moved out of loop. > > By no means can "canonicalization" can achieve this result, because as this transformation need > some context. (It seems the name "cannonicalization" is badly abused in LLVM; it could refers > to this kind of xform. IMO, cannonicalization is sort of blind but consistent restructuring) > > BTW, I did similar stuff before in other compiler, I didn't see any %. Right. Reassociate ranks expressions by their order in the IR, so...

...y can moved as early as possible. Restructuring expr this expr is also able to reduce the critical path even if no sub-expr is moved out of loop. By no means can "canonicalization" can achieve this result, because as this transformation need some context. (It seems the name "cannonicalization" is badly abused in LLVM; it could refers to this kind of xform. IMO, cannonicalization is sort of blind but consistent restructuring) BTW, I did similar stuff before in other compiler, I didn't see any %. On 4/23/13 6:48 AM, Jeroen Dobbelaere wrote: > Hi, > > I am investi...

...Restructuring expr this expr is also able to reduce the critical path even if no sub-expr is > > moved out of loop. > > > > By no means can "canonicalization" can achieve this result, because as this transformation need > > some context. (It seems the name "cannonicalization" is badly abused in LLVM; it could refers > > to this kind of xform. IMO, cannonicalization is sort of blind but consistent restructuring) > > > > BTW, I did similar stuff before in other compiler, I didn't see any %. > > Right. Reassociate ranks expressions by th...

...this expr is also able to reduce the critical path even if no sub-expr is > > > moved out of loop. > > > > > > By no means can "canonicalization" can achieve this result, because as this transformation need > > > some context. (It seems the name "cannonicalization" is badly abused in LLVM; it could refers > > > to this kind of xform. IMO, cannonicalization is sort of blind but consistent restructuring) > > > > > > BTW, I did similar stuff before in other compiler, I didn't see any %. > > > > Right. Reassociat...

Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add

The following is legal LLVM code in which ptr, ptr2, and ptr3 are all aliases: %struct = type { int, int } implementation int %p() { %ptr1 = alloca %struct %ptr2 = getelementptr %struct* %ptr1 %ptr3 = getelementptr %struct* %ptr2, uint 0 %pint = getelementptr %struct* %ptr3, uint 0, ubyte 0 %rval = load int* %pint ret int %rval } Should our pass a) ignore this, not replace %ptr1,

>I think that the first step would be to expose Target Lowering Interface (TLI) to OPT's IR-level passes. By "lowering", we assume the bitcode is more abstract than the machine code. However, in some situations, it is just opposite. For instance, some architectures support vectorization of min/max/saturated-{add,sub)/conditional-assignment/etc/../etc. We need to detect such

...le to reduce the critical path even if no sub-expr is > > > > moved out of loop. > > > > > > > > By no means can "canonicalization" can achieve this result, because as this transformation need > > > > some context. (It seems the name "cannonicalization" is badly abused in LLVM; it could refers > > > > to this kind of xform. IMO, cannonicalization is sort of blind but consistent restructuring) > > > > > > > > BTW, I did similar stuff before in other compiler, I didn't see any %. > > > > &g...

...for each loop If the first PHI node in the header block for the loop is recognizable as an induction variable... for each exit block find predecessor in loop look at the terminator, see if it uses the indvar. This uses the fact that the induction variable cannonicalization pass guarantees that the cannonical induction variable will be the first phi node in the header block, if there is one. Otherwise it's not too different. You can use any traversal of the loop nesting tree, but my analyses and transformations want to do the "more nested" loops befor...

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on -

I mistakenly not cc’ed the list. On Oct 23, 2013, at 8:28 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 October 2013 14:13, Arnold <aschwaighofer at apple.com> wrote: >> What I am proposing for interleaved data vectorization would not transform the loop before vectorization (because there is not much you can do in the general case). There would not be a need

In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so and so LLVM doesn’t vectorize this loop even if we try to force it. The following loop will be vectorized if we force it: int foo(int * A, int * B, int n, int k) { for (int i = 0; i < 1024; ++i) A[i] += B[i*k]; } So will this loop: int foo(int * restrict A, int

Hi, We are starting to work on an LLVM loop vectorizer. There's number of different projects that already vectorize LLVM IR. For example Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, AnySL, just to name a few. I think that it would be great if we could collaborate on the areas that are shared between the different projects. I think that refactoring LLVM in away that