search for: canonicalized

Hello all, I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load

On 09/08/2013 08:03 PM, Star Tan wrote: > Hello all, > > > I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Interesting. > Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or

Hello all, I have evaluated the compile-time and execution-time performance of Polly canonicalization passes. Details can be referred to http://188.40.87.11:8000/db_default/v4/nts/recent_activity. There are four runs: pollyBasic (run 45): clang -O3 -Xclang -load -Xclang LLVMPolly.so pollyNoGenSCEV (run 44): clang -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-codegen-scev

At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/08/2013 08:03 PM, Star Tan wrote: >> Hello all, >> >> >> I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. > >Interesting. > >>

Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity I mainly care about the compile-time and execution time impact for the following cases: pBasic (run 45): clang -O3 -load LLVMPolly.so pNoGenSCEV (run 44): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly -polly-optimizer=none -polly-code-generator=none pNoGenSCEV_nocan (run 47): same option

At 2013-09-09 13:07:07,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/09/2013 05:18 AM, Star Tan wrote: >> >> At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/08/2013 08:03 PM, Star Tan wrote: >>> Also, I wonder if your runs include the dependence analysis. If this is >>> the

...gt; > > > That's good. Anyway I already have a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > > > We already canonicalize. We canonicalize in the other direction: > https://github.com/llvm...

Hi, I observed below behavior with Instruction combiner (visitMul Canonicalization) It tries to convert "(X+C1)*C2" to "X*C2+C1*C2" While transforming if operation is guaranteed to not overflow it does not reflect same property to transformed instructions. Consider following scenarios: 1) If input is ((X+C1)*C2)<nsw> Then post canonicalization output should be

...have a patch that is doing invariant >>> group >>> > dependence across BBs, so I guess it make sense to push it upstream to >>> push >>> > the bar higher. >>> > But I think we are getting a little bit of topic - should gep 0 be >>> > canonicalized to bitcast? >>> > >>> >>> Are memdep/memssa the only possible passes that could benefit from >>> such a canonicalization or you can think of other cases when this can >>> be useful? >>> >> >> We already canonicalize. We canonical...

I committed a change to fix pr4731 yesterday but after thinking about it some more, I'd like to get other opinions about this. Chris and I talked last week about the need to canonicalize the types used for Neon vector shuffles so that they get CSEd. I guess this was an issue that came up for SSE. For pr4731, I changed llvm-gcc to canonicalize a bitwise vector operation to use i32

...hat's good. Anyway I already have a patch that is doing invariant group >> > dependence across BBs, so I guess it make sense to push it upstream to >> push >> > the bar higher. >> > But I think we are getting a little bit of topic - should gep 0 be >> > canonicalized to bitcast? >> > >> >> Are memdep/memssa the only possible passes that could benefit from >> such a canonicalization or you can think of other cases when this can >> be useful? >> > > We already canonicalize. We canonicalize in the other direction: >...

...hat's good. Anyway I already have a patch that is doing invariant group >> > dependence across BBs, so I guess it make sense to push it upstream to >> push >> > the bar higher. >> > But I think we are getting a little bit of topic - should gep 0 be >> > canonicalized to bitcast? >> > >> >> Are memdep/memssa the only possible passes that could benefit from >> such a canonicalization or you can think of other cases when this can >> be useful? >> >> >> We already canonicalize. We canonicalize in the other directi...

...houldn't have two constant factors, missed a canonicalize"); assert(NumAddedValues > 1 && "Each occurrence should contribute a value”); My understanding is that these assertions enforce that when processing an expression tree, we expect that the nodes have already been canonicalized by Reassociate. I infer that there should be *one* canonicalization for a function and it should be deterministic, i.e. if I run Reassociate two times I expect that the second one does not make any change. However right now we are far from that. I have multiple patches in flight to improve the si...

> On Feb 20, 2015, at 11:14 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > >> On 2015-Feb-20, at 09:44, Frédéric Riss <friss at apple.com> wrote: >> >> Speaking of deduplication of filenames. I think we discussed that in the early stages of your work, but I just wanted to make sure I remember correctly: the new debug hierarchy will allow

On Aug 17, 2009, at 7:15 AM, Bob Wilson wrote: > I committed a change to fix pr4731 yesterday but after thinking about > it some more, I'd like to get other opinions about this. Chris and I > talked last week about the need to canonicalize the types used for > Neon vector shuffles so that they get CSEd. I guess this was an issue > that came up for SSE. > > For pr4731, I

...gt; > > > That's good. Anyway I already have a patch that is doing invariant group > > dependence across BBs, so I guess it make sense to push it upstream to > push > > the bar higher. > > But I think we are getting a little bit of topic - should gep 0 be > > canonicalized to bitcast? > > > > Are memdep/memssa the only possible passes that could benefit from > such a canonicalization or you can think of other cases when this can > be useful? > We already canonicalize. We canonicalize in the other direction: https://github.com/llvm-mirror/llvm/b...

On 09/17/2013 04:12 AM, Star Tan wrote: > Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity Hi Star Tan, thanks for this very extensive analysis. The results look very interesting. As you found out, just removing some canonicalization passes will reduce compile time, but this reduction may in large part being due to Polly not being able to

So, we've run into some test cases which are pretty alarming. When inlining code in various different paths we can end up with this IR: define void @f(float* %value, i8* %b) { entry: %0 = load float* %value, align 4 %1 = bitcast i8* %b to float* store float %0, float* %1, align 1 ret void } define void @g(float* %value, i8* %b) { entry: %0 = bitcast float* %value to i32* %1 =

...like memcpy opt, licm, etc) > > > That's good. Anyway I already have a patch that is doing invariant group > dependence across BBs, so I guess it make sense to push it upstream to push > the bar higher. > But I think we are getting a little bit of topic - should gep 0 be > canonicalized to bitcast? > Are memdep/memssa the only possible passes that could benefit from such a canonicalization or you can think of other cases when this can be useful?

...ally happens :) ) define i32 @f(i1 %x, i1 %y) { %x.zext = ... %y.zext = ... %a = add nuw i32 %x.zext, %y.zext ret i32 %a } but we've now lost information -- we no longer know that %a is 0 or 1 -- it can also be 2. This would not happen if we always canonicalized zext i1 C to iN to select C, iN 1, iN 0 -- Sanjoy