[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-15 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #25 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:05:22 2016
New Revision: 234237

URL: https://gcc.gnu.org/viewcvs?rev=234237=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-15 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #24 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:54 2016
New Revision: 234236

URL: https://gcc.gnu.org/viewcvs?rev=234236=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-15 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #23 from Alan Modra  ---
Author: amodra
Date: Tue Mar 15 22:04:42 2016
New Revision: 234235

URL: https://gcc.gnu.org/viewcvs?rev=234235=gcc=rev
Log:
Fix thinko in indirect_jump_optimize

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-10 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Alan Modra  ---
Fixed

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-10 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #21 from Alan Modra  ---
Author: amodra
Date: Thu Mar 10 10:48:58 2016
New Revision: 234103

URL: https://gcc.gnu.org/viewcvs?rev=234103=gcc=rev
Log:
PR69195, Reload confused by invalid reg_equiv

Optimizing indirect jumps to direct jumps, and deleting dead insns can
lead to changes in register lifetimes, which in turn can result in bad
reg_equiv info being passed to reload.  So do these tasks before
calculating reg_equiv info.

gcc/
PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (recorded_label_ref): Delete.
(update_equiv_regs): Return void.
(indirect_jump_optimize): New function.
(ira): Call indirect_jump_optimize and delete_trivially_dead_insns
before regstat_compute_ri.  Don't rebuild_jump_labels here.
gcc/testsuite/
* gcc.dg/pr69195.c: New.
* gcc.dg/pr69238.c: New.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr69195.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr69238.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-10 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #20 from Alan Modra  ---
Author: amodra
Date: Thu Mar 10 10:48:14 2016
New Revision: 234102

URL: https://gcc.gnu.org/viewcvs?rev=234102=gcc=rev
Log:
PR69195, Reload confused by invalid reg_equiv

Optimizing indirect jumps to direct jumps, and deleting dead insns can
lead to changes in register lifetimes, which in turn can result in bad
reg_equiv info being passed to reload.  So do these tasks before
calculating reg_equiv info.

gcc/
PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (recorded_label_ref): Delete.
(update_equiv_regs): Return void.
(indirect_jump_optimize): New function.
(ira): Call indirect_jump_optimize and delete_trivially_dead_insns
before regstat_compute_ri.  Don't rebuild_jump_labels here.
gcc/testsuite/
* gcc.dg/pr69195.c: New.
* gcc.dg/pr69238.c: New.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69195.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr69238.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-10 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #19 from Alan Modra  ---
Author: amodra
Date: Thu Mar 10 10:47:13 2016
New Revision: 234101

URL: https://gcc.gnu.org/viewcvs?rev=234101=gcc=rev
Log:
PR69195, Reload confused by invalid reg_equiv

Optimizing indirect jumps to direct jumps, and deleting dead insns can
lead to changes in register lifetimes, which in turn can result in bad
reg_equiv info being passed to reload.  So do these tasks before
calculating reg_equiv info.

gcc/
PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (recorded_label_ref): Delete.
(update_equiv_regs): Return void.
(indirect_jump_optimize): New function.
(ira): Call indirect_jump_optimize and delete_trivially_dead_insns
before regstat_compute_ri.  Don't rebuild_jump_labels here.
Delete update_regstat.
gcc/testsuite/
* gcc.dg/pr69195.c: New.
* gcc.dg/pr69238.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr69195.c
trunk/gcc/testsuite/gcc.dg/pr69238.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-10 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2016-03/msg00361.ht |patches/2016-03/msg00604.ht
   |ml  |ml
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-08 Thread zsojka at seznam dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #18 from Zdenek Sojka  ---
(In reply to Bernd Schmidt from comment #17)
> Is this reproducible on trunk? What are the exact flags required to pass to
> cc1? I'm not getting a difference in REG_EQUIV notes between -fdce and
> -fno-dce.

Yes, it still fails in trunk (r234047).
cc1 commandline is:
/repo/gcc-trunk/binary-trunk-234047-checking-yes-rtl-df-nographite-powerpc64/libexec/gcc/powerpc64-unknown-linux-gnu/6.0.0/cc1
-quiet -iprefix
/repo/gcc-trunk/binary-trunk-234047-checking-yes-rtl-df-nographite-powerpc64/bin/../lib/gcc/powerpc64-unknown-linux-gnu/6.0.0/
-D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix testcase.c -quiet -dumpbase
testcase.c -auxbase testcase -O3 -fno-dce -fno-forward-propagate -o
/tmp/ccnx8kGq.s

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-04 Thread bernds at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #17 from Bernd Schmidt  ---
Is this reproducible on trunk? What are the exact flags required to pass to
cc1? I'm not getting a difference in REG_EQUIV notes between -fdce and
-fno-dce.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-04 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Alan Modra  changed:

   What|Removed |Added

  Attachment #37863|0   |1
is obsolete||

--- Comment #16 from Alan Modra  ---
Comment on attachment 37863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37863
delete bad reg equiv and recreate store notes

Corrected version of third patch in URL

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #15 from Alan Modra  ---
Blah, that last patch segfaults all over the place.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Alan Modra  changed:

   What|Removed |Added

  Attachment #37862|0   |1
is obsolete||

--- Comment #14 from Alan Modra  ---
Created attachment 37863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37863=edit
delete bad reg equiv and recreate store notes

This patch re-runs the second pass of update_equiv_regs after deleting bad reg
equiv notes.  I suppose the only real advantage of this over simply running
delete_trivially_dead_insns early, is that this patch covers the case where
delete_unreachable_blocks changes register lifetimes in a way that makes the
reg equiv information bad for reload.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #13 from Alan Modra  ---
Created attachment 37862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37862=edit
delete bad reg_equiv

A patch like this one that deletes reg_equiv notes that become invalid
according to validate_equiv_mem after delete_trivially_dead_insns, results in
code requiring more non-volatile regs than simply running delete_trivially_dead
insns early.  The notes created in the second pass of update_equiv_regs (that I
thought invalid) are used by reload to move stores up.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #12 from Alan Modra  ---
Created attachment 37857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37857=edit
workaround patch

Given the problems identified with notes (and of course the notes are what
drives reg_equiv_init passed on to reload), one simple fix is to run
delete_trivially_dead_insns early in ira.  I've left the later call in, but
that might be better moved into the optimize && rebuild_p block.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-03-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #11 from Alan Modra  ---
The first thing I noticed when looking at rtl dumps for this bug is
that -fno-dce makes a difference to the REG_EQUIV notes emitted by the
ira pass.

With -fno-dce we get this:
(insn 6 41 8 2 (set (reg:DI 173)
(mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) /src/tmp/pr69195.c:15 549
{*movdi_internal64}
 (expr_list:REG_EQUIV (mem/u/c:DI (reg/f:DI 172) [0  S8 A32])
(nil)))

With -fdce we get:
(insn 6 41 8 2 (set (reg:DI 173)
(mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) /src/tmp/pr69195.c:15 549
{*movdi_internal64}
 (expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 96 [0x60])) [1 a+0 S8 A128])
(nil)))

I think the second note is invalid.  Reg 173 is *not* the same as the
stack location at this point.  (It is after the reg has been stored.)

The reason the notes are different is that in the -fno-dce case
ira.c:3566 call to validate_equiv_mem returns true, whereas when dce
is enabled it returns false due to hitting a REG_DEAD for reg 172
(ira.c:2992) before seeing REG_DEAD for reg 173.  This in turn leads
to ira.c:3677 setting the note.  It's interesting that ira.c:3679
correctly comments that the store is the insn making the equivalence,
not the load, but leaves the note of the load regardless..

Another curious fact is that ira with -fno-dce deletes the same dead
loads removed by -fdce, but in this case by the call to
delete_trivially_dead_insns in ira, *after* the update_equiv_regs call
that creates the reg notes.  Deleting those insns of course moves the
REG_DEAD note for reg 172 earlier, before the store that goes wrong.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-02-03 Thread vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #10 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #9)
> I think we have another bug in addition to the bug where we reuse a register
> that is already in use.  We have the rtl below which is used to initialize
> a[] before the call to foo:
> 
> (insn 5 39 40 2 (set (reg/f:DI 172)
> (unspec:DI [
> (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> (reg:DI 2 2)
> ] UNSPEC_TOCREL)) bug.c:6 622 {*tocrefdi}
>  (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> (nil)))
> (insn 40 5 6 2 (set (reg:DI 3 3)
> (plus:DI (reg/f:DI 113 sfp)
> (const_int 96 [0x60]))) bug.c:9 81 {*adddi3}
>  (nil))
> (insn 6 40 8 2 (set (reg:DI 173)
> (mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) bug.c:6 540
> {*movdi_internal64}
>  (nil))
> (insn 8 6 10 2 (set (reg:DI 174)
> (mem/u/c:DI (plus:DI (reg/f:DI 172)
> (const_int 8 [0x8])) [0  S8 A32])) bug.c:6 540
> {*movdi_internal64}
>  (nil))
> (insn 10 8 12 2 (set (reg:DI 175)
> (mem/u/c:DI (plus:DI (reg/f:DI 172)
> (const_int 16 [0x10])) [0  S8 A32])) bug.c:6 540
> {*movdi_internal64}
>  (nil))
> 
> .
> 
> (insn 7 29 9 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
> (const_int 96 [0x60])) [1 aD.2356+0 S8 A128])
> (reg:DI 173)) bug.c:6 540 {*movdi_internal64}
>  (expr_list:REG_DEAD (reg:DI 173)
> (nil)))
> (insn 9 7 11 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
> (const_int 104 [0x68])) [1 aD.2356+8 S8 A64])
> (reg:DI 174)) bug.c:6 540 {*movdi_internal64}
>  (expr_list:REG_DEAD (reg:DI 174)
> (nil)))
> (insn 11 9 13 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
> (const_int 112 [0x70])) [1 aD.2356+16 S8 A128])
> (reg:DI 175)) bug.c:6 540 {*movdi_internal64}
>  (expr_list:REG_DEAD (reg:DI 175)
> (nil)))
> 
> During allocation, we happily allocate volatiles to the above pseudos until
> run out...when trying to allocate pseudos 173 and 174.  Having run out of
> volatile regs, we allocate non-volatiles to pseudos 173 and 174.  However,
> in assign_hard_reg(), we think it's cheaper to use memory than to use a
> non-volatile, so we proactively spill 173 and 174:
> 
>   Popping a34(r174,l0)  -- (memory is more profitable 0 vs 7) spill!
>   Popping a35(r173,l0)  -- (memory is more profitable 0 vs 7) spill!
> 
> The above says the cost of using memory is zero, which doesn't seem correct
> to me.  In fact, all of the pseudos being used to initialize a[] have a zero
> memory cost, but since the volatile regs also have zero cost, we don't spill
> them.  It doesn't seem correct to me, that these pseudos have a zero memory
> cost.  I'll try to track down where that occurs.

Thanks, Peter.  The memory cost for 174 and 173 can not be zero as we will have
mem-mem move.  I think the problem is coming from ira-costs.c which was pretty
much adopted from the old RA.  I want to rewrite long ago this code as the
algorithm does not look right to me.  The algorithm ignores the fact that
operands should be from the same alternative.  Frequently, it takes best cost
for one operand from one alternative and best cost for another operand from
different alternative.

I'll try to find time to rewrite ira-costs.c for GCC7 and see the results.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-29 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #9 from Peter Bergner  ---
I think we have another bug in addition to the bug where we reuse a register
that is already in use.  We have the rtl below which is used to initialize a[]
before the call to foo:

(insn 5 39 40 2 (set (reg/f:DI 172)
(unspec:DI [
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(reg:DI 2 2)
] UNSPEC_TOCREL)) bug.c:6 622 {*tocrefdi}
 (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(nil)))
(insn 40 5 6 2 (set (reg:DI 3 3)
(plus:DI (reg/f:DI 113 sfp)
(const_int 96 [0x60]))) bug.c:9 81 {*adddi3}
 (nil))
(insn 6 40 8 2 (set (reg:DI 173)
(mem/u/c:DI (reg/f:DI 172) [0  S8 A32])) bug.c:6 540
{*movdi_internal64}
 (nil))
(insn 8 6 10 2 (set (reg:DI 174)
(mem/u/c:DI (plus:DI (reg/f:DI 172)
(const_int 8 [0x8])) [0  S8 A32])) bug.c:6 540
{*movdi_internal64}
 (nil))
(insn 10 8 12 2 (set (reg:DI 175)
(mem/u/c:DI (plus:DI (reg/f:DI 172)
(const_int 16 [0x10])) [0  S8 A32])) bug.c:6 540
{*movdi_internal64}
 (nil))

.

(insn 7 29 9 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 96 [0x60])) [1 aD.2356+0 S8 A128])
(reg:DI 173)) bug.c:6 540 {*movdi_internal64}
 (expr_list:REG_DEAD (reg:DI 173)
(nil)))
(insn 9 7 11 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 104 [0x68])) [1 aD.2356+8 S8 A64])
(reg:DI 174)) bug.c:6 540 {*movdi_internal64}
 (expr_list:REG_DEAD (reg:DI 174)
(nil)))
(insn 11 9 13 2 (set (mem/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 112 [0x70])) [1 aD.2356+16 S8 A128])
(reg:DI 175)) bug.c:6 540 {*movdi_internal64}
 (expr_list:REG_DEAD (reg:DI 175)
(nil)))

During allocation, we happily allocate volatiles to the above pseudos until run
out...when trying to allocate pseudos 173 and 174.  Having run out of volatile
regs, we allocate non-volatiles to pseudos 173 and 174.  However, in
assign_hard_reg(), we think it's cheaper to use memory than to use a
non-volatile, so we proactively spill 173 and 174:

  Popping a34(r174,l0)  -- (memory is more profitable 0 vs 7) spill!
  Popping a35(r173,l0)  -- (memory is more profitable 0 vs 7) spill!

The above says the cost of using memory is zero, which doesn't seem correct to
me.  In fact, all of the pseudos being used to initialize a[] have a zero
memory cost, but since the volatile regs also have zero cost, we don't spill
them.  It doesn't seem correct to me, that these pseudos have a zero memory
cost.  I'll try to track down where that occurs.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-28 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #8 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #7)
> So it is probably a long lasting latent bug of reload.  It would be better
> to work on switching ppc to LRA by default.  But it might be too late for
> gcc6 and somebody should fix it in reload.

We are planning on moving ppc to LRA, but there are still a bug or two that
needs fixing before we switch to LRA and now it's too late for gcc6.


> Unfortunately I have not time to do this.

If no one else is looking into this (let me know if you are), I'll have a look.



> It is a legitimate.  Reload pass decides later to use equiv memory extending
> range of p172 and doesn't check that it is wrong.
> 
> LRA also uses equiv memory with p172 for a spilled pseudo but it *checks*
> that the transformation is legitimate.  It finds that it is wrong and makes
> a correction by spilling p172 first and then reassigning free r30 to it.
> 
> As I remember the old global and local passes did not take equivalences into
> account and could have assigned p172 and p185 to the same reg as well.

Vlad, can you point me to the LRA code that checks whether using the equiv
memory is legitimate or not before using it?  I'm guessing I'll need to make a
similar change to reload, so I'd like to see how LRA is doing it.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-25 Thread vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #7 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #4)
> I think I can reproduce it with powerpc64le-linux too (though, have just
> eyeballed assembly, not tried to run it).
> This looks like an IRA or reload problem to me.
> In *.ira we have 12 loads from *.LANCHOR0 first (8 DImore reads from *.LC0
> and 4 DImore reads from *.LC1), followed by stores to stack locations:
> 5: r172:DI=unspec[`*.LANCHOR0',%2:DI] 47
>   REG_EQUIV `*.LANCHOR0'

I believe it is a reload problem not IRA one.  IRA assigns r9 to p185 and p172
as p172 dies and 185 is born in insn

   29: r185:DI=[r172:DI+0x58]
  REG_DEAD r172:DI

It is a legitimate.  Reload pass decides later to use equiv memory extending
range of p172 and doesn't check that it is wrong.

LRA also uses equiv memory with p172 for a spilled pseudo but it *checks* that
the transformation is legitimate.  It finds that it is wrong and makes a
correction by spilling p172 first and then reassigning free r30 to it.

As I remember the old global and local passes did not take equivalences into
account and could have assigned p172 and p185 to the same reg as well.

So it is probably a long lasting latent bug of reload.  It would be better to
work on switching ppc to LRA by default.  But it might be too late for gcc6 and
somebody should fix it in reload.  Unfortunately I have not time to do this.


> The bug goes away
> with -mlra it seems.  IRA computes the same dispositions, but LRA seems to
> ignore the fact that pseudo has been assigned r9 and uses r30 instead for
> it, so everything is fine.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #5 from Jakub Jelinek  ---
*** Bug 69238 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-22 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

--- Comment #6 from Jakub Jelinek  ---
Once we have a fix, please make sure to also check the PR69238 testcase and add
it into the testsuite.

[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate

2016-01-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
   Priority|P3  |P2
  Component|target  |rtl-optimization