search for: cannonicalize

...e 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 to "the pre-legalize optimization" ? -- Tzu-Chien Chiu, Computer Graphics Guy,...

On Mar 12, 2014, at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 12, 2014 at 3:50 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > 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 > > But, why? > > I'm moderately sure that neither C nor C++

On Apr 23, 2013, at 10:37 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. > > If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that > the earlier definition of the sub-expression is permute earlier in

As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that the earlier definition of the sub-expression is permute earlier in the resulting expr. e.g. outer-loop1 x= outer-loop2 y =

It's an interesting problem. The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf I can't tell, quickly, what's going on in Reassociate; as usual, the documentation resolutely avoids giving any credit for the ideas. Why is that?

On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > It's an interesting problem. > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf > I can't tell, quickly, what's going on

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

On Thu, Apr 25, 2013 at 9:18 AM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > > It's an interesting problem. > > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > > Cooper gives a nice intro in one of his

> 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. I can try. :) It looks like you're running into problems because we don't perform "Linear Function Test Replacement". This optimization would reduce the amount of code

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