search for: canonicalize

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/llv...

...*C2) in both scenarios (1 & 2). To me this looks like a limitation with canonicalization where its missing guarantee to not overflow property. Please confirm my understanding. <File: InstCombineMulDivRem.cpp > 168 Instruction *InstCombiner::visitMul(BinaryOperator &I) { 268 // Canonicalize (X+C1)*CI -> X*CI+C1*CI. 269 { 270 Value *X; 271 Constant *C1; 272 if (match(Op0, m_OneUse(m_Add(m_Value(X), m_Constant(C1))))) { 273 Value *Mul = Builder->CreateMul(C1, Op1); 274 // Only go forward with the transform if C1*CI simplifies to a tidier...

...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 canonica...

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 elements. For these operations, the type doesn't matter since the vector are treated as...

...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: &gt...

...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 direct...

Hi, I encountered some bugs in Reassociate [1] where we are hitting some assertions: assert(!Duplicates.count(Factor) && "Shouldn'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 *...

...elative to the current directory of the compilation." I think that at the time I had interpreted that has “if the user passes -I../include to the compiler, le line table should list ../include as a directory in the line table”. I think my interpretation was too strict though and that we could canonicalize the file/dir names as we’d like. The compilation dir will always be there as a special entry. It’s the implicit entry 0 in the directory list, but it’s value is not stored in the line table, it is a normal string that is referenced by the TAG_compile_unit DIE. If it is extracted from an MDFile, we...

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 changed llvm-gcc to canonicalize a bitwise vector > operation to use i32 elements. For these operations, the type doesn't > matter since the v...

...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/...

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

...tcast float* %value to i32* %1 = load i32* %0, align 4 %2 = bitcast i8* %b to i32* store i32 %1, i32* %2, align 1 ret void } Now, I don't really care one way or the other about these two IR inputs, but it's pretty concerning that we get these two equivalent bits of code and nothing canonicalizes to one or the other. So, the naive first blush approach here would be to canonicalize on the first -- it has fewer instructions after all -- but I don't think that's the right approach for two reasons: 1) It will be a *very* narrow canonicalization that only works with overly specific se...

...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