search for: canonicalizations

Displaying 20 results from an estimated 1139 matches for "canonicalizations".

Did you mean: canonicalization
2013 Sep 08
2
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV 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): -O3 -Xclang -load
2013 Sep 08
0
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
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
2013 Sep 14
0
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
...ly::createCodePreparationPass()); } As shown on http://188.40.87.11:8000/db_default/v4/nts/47?baseline=45&compare_to=45, the extra compile-time overhead is very small (5.04% at most) by removing all optional Polly canonicalization passes. However, I think it is not practical to remove all these canonicalizations for the sake of Polly optimization performance. I would further evaluate Polly's performance (with optimization and code generation) in the case all optional canonicalization passes are removed. As a simple informal conclusion, I think we should revise Polly's canonicalization passes. At...
2013 Sep 09
4
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
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. > >>
2013 Sep 17
4
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
...ly::createCodePreparationPass()); } As shown on http://188.40.87.11:8000/db_default/v4/nts/47?baseline=45&compare_to=45, the extra compile-time overhead is very small (5.04% at most) by removing all optional Polly canonicalization passes. However, I think it is not practical to remove all these canonicalizations for the sake of Polly optimization performance. I would further evaluate Polly's performance (with optimization and code generation) in the case all optional canonicalization passes are removed. As a simple informal conclusion, I think we should revise Polly's canonicalization passes. At...
2013 Sep 13
2
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
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
2016 Dec 24
0
[canonicalization] GEP 0, 0
On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > > > > On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev
2015 Apr 15
2
[LLVMdev] Instruction combiner multiplication canonicalization
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
2016 Dec 23
2
[canonicalization] GEP 0, 0
On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Dec 23, 2016 at 1:01 PM,
2009 Aug 17
2
[LLVMdev] canonicalizing types for vector operations
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
2016 Dec 23
0
[canonicalization] GEP 0, 0
2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>: > > > On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski >> <piotr.padlewski at gmail.com> wrote: >> > >> > >> > On Dec 23, 2016 19:47, "Daniel
2016 Dec 24
2
[canonicalization] GEP 0, 0
On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> >> 2016-12-23 22:17 GMT+01:00 David
2015 Feb 02
2
[LLVMdev] Reassociate and Canonicalization of Expressions
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
2015 Feb 20
2
[LLVMdev] Questions before moving the new debug info hierarchy into place
> 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
2009 Aug 17
0
[LLVMdev] canonicalizing types for vector operations
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
2016 Dec 23
2
[canonicalization] GEP 0, 0
On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > > > > > > On Dec 23, 2016 19:47, "Daniel Berlin" <dberlin at dberlin.org> wrote: > > > > Define soon? > > My guess is 1 year or less.
2013 Sep 18
0
[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
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
2015 Jan 21
5
[LLVMdev] RFC: Missing canonicalization in LLVM
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 =
2016 Dec 23
0
[canonicalization] GEP 0, 0
On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski <piotr.padlewski at gmail.com> wrote: > > > On Dec 23, 2016 19:47, "Daniel Berlin" <dberlin at dberlin.org> wrote: > > Define soon? > My guess is 1 year or less. > (I've already seen patches to start converting most remaining memdep uses, > like memcpy opt, licm, etc) > > > That's good.
2016 Sep 29
2
IR canonicalization: select or bool math?
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