search for: canonicalization

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

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 33, 34) > *pNoGen with SCEV...

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

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

...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 with pNoGenSCEV but replace the LLVMPolly.so by removing all Polly canonicalization passes pNoGenSCEV_procomb (run 51): same option with pNoGenSCEV but replace the LLVMPolly.so by removing only the "InstructionCombining" and "PromoteMemoryToRegister" canonicalization passes pOptSCEV (run 48): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly pOptSCEV_noc...

...chmarks/VersaBench/ecbdes/ecbdes 21.05% >> When I look into the compile-time for the flop benchmark using "-ftime-report", I find the extra compile-time overhead mainly comes from the "Combine redundant instructions" pass. >> the top 5 passes when compiled with Polly canonicalization passes: >> ---User Time--- --User+System-- ---Wall Time--- --- Name --- >> 0.0160 ( 20.0%) 0.0160 ( 20.0%) 0.0164 ( 20.8%) Combine redundant instructions >> 0.0120 ( 15.0%) 0.0120 ( 15.0%) 0.0138 ( 17.5%) X86 DAG->DAG Instruction Selection >>...

...Bs, 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/blob/master/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024 > > > Intresting. So what is the right s...

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

...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/blob/master/l >> ib/Transforms/InstCombine/InstCombineCasts.cpp#L2024 >> &g...

...et 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 a bunch of bits. I was thinking that we should do the canonicalization for all the bitwise vector operations. But is llvm-gcc the right place to do that? The changes that I discussed with Chris were in code gen. It seems like the front-end is not the best place to do that kind of optimization and that ideally the optimizer would be able to recognize that bi...

...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/blob/master/ > lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024 > > Intresting. So what is th...

...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/blob/master/ >> lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024 >> >> &...

...;); 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 situation, but the situation is still not perfect. Before going further...

...gt; canonicalizing it to basename/dirname, etc.), and add a `cwd:` > to the compile unit.) As stated above, I think we are free to canonicalize as we wish. > David also pointed out (in a previous thread about this) that > the frontend (or `DIBuilder`) might be the right location for > canonicalization. Certainly, we couldn't canonicalize `..` > references without access to the filesystem (at least not on > POSIX platforms), but maybe we don't care about that anyway? What I attempted to do in the past was exactly that, canonicalize ‘..’ in the paths (The lldb folks would have love...

...s 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 a bunch of bits. I was > thinking that we should do the canonicalization for all the bitwise > vector operations. But is llvm-gcc the right place to do that? The > changes that I discussed with Chris were in code gen. It seems like > the front-end is not the best place to do that kind of optimization > and that ideally the optimizer would be able to recog...

...Bs, 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/blob/master/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024 > _______________________________________________ > LLV...

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 optimise certain pieces of code. Instead of removing canonicalization passes, I believe we may want to move Polly to a later place in the pass manager. Possibly at the beginning of the lo...

...ese 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 sets of casted pointers. 2) It doesn't effectively move us toward the optimizer treating IR with different pointee types for pointer types indistinguishably. Some day, I continue to think we should get rid of the pointee types entirely. To see why #1 and #2...

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

My gut tells me that Hal is right, and we should prefer zexts as long as the select boils down to one instruction, but let me go against my intuition and try to list two reasons why we should prefer selects: * Folding operations into selects: it is trivial to transform f(select X, Const0, Const1) to select X, f(Const0), f(Const1), while doing that can be difficult for zexts. define