llvm dev - Feb 2016 - [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>

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>

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>