Tim Shen via llvm-dev
2016-Feb-20 01:10 UTC
[llvm-dev] [VSXFMAMutate] OldFMAReg may be wrongly rewritten
Example: target triple = "powerpc64le-unknown-linux-gnu" define void @TestFoo() { entry_bb: br label %loop_bb loop_bb: %tmp = load float, float* undef %tmp1 = fmul float %tmp, 0x401F25E360000000 %tmp2 = fadd float %tmp1, 0x3FC1A7B960000000 %tmp3 = select i1 undef, float 0x401F25E360000000, float %tmp2 store float %tmp3, float* undef br label %loop_bb } The code above is triggering a assertion failure when adjusting the live intervals, since OldFMAReg (%vreg12 in debug info) is actually defined in two blocks. I wonder if we can fix this by making the transformation simpler, that is, instead of doing: %vreg12<def> = COPY %vreg7; VSSRC:%vreg12,%vreg7 %vreg12<def,tied1> = XSMADDASP %vreg12<tied0>, %vreg0, %vreg4; VSSRC:%vreg12,%vreg0 F4RC:%vreg4 -> %vreg0<def,tied1> = XSMADDMSP %vreg0<tied0>, %vreg4, %vreg7; VSSRC:%vreg0,%vreg7 F4RC:%vreg4 , we do: %vreg12<def> = COPY %vreg7; VSSRC:%vreg12,%vreg7 %vreg12<def,tied1> = XSMADDASP %vreg12<tied0>, %vreg0, %vreg4; VSSRC:%vreg12,%vreg0 F4RC:%vreg4 -> %vreg0<def,tied1> = XSMADDMSP %vreg0<tied0>, %vreg4, %vreg7; VSSRC:%vreg0,%vreg7 F4RC:%vreg4 %vreg12<def> = COPY %vreg0; VSSRC:%vreg12,%vreg0 and count on copy elimination to eliminate the introduced copy (which should be easy?). Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160220/feb65fc3/attachment.html>
Tim Shen via llvm-dev
2016-Feb-22 21:06 UTC
[llvm-dev] [VSXFMAMutate] OldFMAReg may be wrongly rewritten
On Fri, Feb 19, 2016 at 5:10 PM Tim Shen <timshen at google.com> wrote:> I wonder if we can fix this by making the transformation simpler, that is, > instead of doing: >I wrote a prototype (see attach) for this idea, it actually improves some of the test cases (e.g. fma-assoc.ll: test_FMADD_ASSOC1), but pessimize several other cases (e.g. test_FMADD_ASSOC_EXT1). I'm not sure what to do at this point, I have several options: 1) This pass simply omits the optimization for certain cases ("certain" needs to be defined). 2) This pass should never mutate anything out of the block, and may add a copy at the end of the block, if the value is live-out. 3) tune the transformation as I attempted, to make it simpler, working, and producing better result? It seems interesting to get the improvement as my prototype shown without hurting other test cases, but it needs a bit thinking and I'd like to fix the compiler crash soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160222/d1260f2d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: a.diff Type: application/octet-stream Size: 3964 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160222/d1260f2d/attachment.obj>
Tim Shen via llvm-dev
2016-Feb-29 22:21 UTC
[llvm-dev] [VSXFMAMutate] OldFMAReg may be wrongly rewritten
Ping? On Mon, Feb 22, 2016 at 1:06 PM Tim Shen <timshen at google.com> wrote:> On Fri, Feb 19, 2016 at 5:10 PM Tim Shen <timshen at google.com> wrote: > >> I wonder if we can fix this by making the transformation simpler, that >> is, instead of doing: >> > > I wrote a prototype (see attach) for this idea, it actually improves some > of the test cases (e.g. fma-assoc.ll: test_FMADD_ASSOC1), but pessimize > several other cases (e.g. test_FMADD_ASSOC_EXT1). > > I'm not sure what to do at this point, I have several options: > 1) This pass simply omits the optimization for certain cases ("certain" > needs to be defined). > 2) This pass should never mutate anything out of the block, and may add a > copy at the end of the block, if the value is live-out. > 3) tune the transformation as I attempted, to make it simpler, working, > and producing better result? It seems interesting to get the improvement as > my prototype shown without hurting other test cases, but it needs a bit > thinking and I'd like to fix the compiler crash soon. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160229/378f1f15/attachment.html>