[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-03 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

--- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Dec  3 13:16:25 2014
New Revision: 218312

URL: https://gcc.gnu.org/viewcvs?rev=218312root=gccview=rev
Log:
Revert r218266

gcc/

PR rtl-optimization/64151
PR rtl-optimization/64156
* ira-costs.c (scan_one_insn): Revert r218266.

gcc/testsuite/

PR rtl-optimization/64151
PR rtl-optimization/64156
* gcc.target/aarch64/remat1.c: Removed.  Revert r218267.

Removed:
trunk/gcc/testsuite/gcc.target/aarch64/remat1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c
trunk/gcc/testsuite/ChangeLog


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-03 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
Fixed.


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

Michael Meissner meissner at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Dup of PR64151?


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

--- Comment #2 from Michael Meissner meissner at gcc dot gnu.org ---
Note, the fix proposed in PR64151 DOES NOT work on the PowerPC, so it may be a
dup in terms of what change broke the build, but the potential fix needs more
analysis.


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

Michael Meissner meissner at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

--- Comment #3 from Wilco wdijkstr at arm dot com ---
(In reply to Michael Meissner from comment #2)
 Note, the fix proposed in PR64151 DOES NOT work on the PowerPC, so it may be
 a dup in terms of what change broke the build, but the potential fix needs
 more analysis.

The basic issue is similar, we end up with negative mem_cost for some constant
loads due to LEGITIMATE_PIC_OPERAND_P being true for (symbol_ref:SI
(*.LANCHOR0) [flags 0x182]) in:

(insn 41 40 42 9 (set (reg/f:SI 173)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*.LC1) [flags 0x2])
(reg:SI 30 30)
] UNSPEC_TOCREL) [3  S4 A8])) powisf2.c:15 403
{*movsi_internal1}
 (expr_list:REG_EQUIV (symbol_ref:SI (*.LANCHOR0) [flags 0x182])
(nil)))
(insn 42 41 43 9 (set (reg:SF 172)
(mem/u/c:SF (reg/f:SI 173) [1  S4 A32])) powisf2.c:15 409
{movsf_hardfloat}
 (expr_list:REG_DEAD (reg/f:SI 173)
(expr_list:REG_EQUIV (const_double:SF 1.0e+0 [0x0.8p+1])
(nil

The interesting thing here is that the 2nd load is already processed in the
same way (as it is a legitimate constant. The original costs are 264 for r172
and 0 for r273. However if the first load has its mem_cost changed too, then
BOTH r172 and r173 end up with a negative cost (-198 and -66). Also both loads
are single-use and already right next to their use, so in principle don't need
this mem_cost adjustment as they cannot be spilled.

When the first load is rematerialized in reload it seems to be copied
incorrectly (possibly because the REG_EQUIV is lost at some point), resulting
in an odd LC2 symbol:

(insn 80 42 81 9 (set (reg:SI 9 9)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*.LC2) [flags 0x2])
(reg:SI 30 30)
] UNSPEC_TOCREL) [3  S4 A8])) powisf2.c:15 403
{*movsi_internal1}
 (nil))

It seems this issue could happen without the mem_move cost adjustment, say for
example if the first load had been CSEd and used for several constants across a
large function. In that case it might be spilled due to register pressure, so
if reload cannot rematerialize it correctly, it should keep the original load
instruction and force a standard spill/reload instead.

Anyway it looks like this patch has triggered some complex allocation issues,
so it seems best to revert it. I'll get someone to do that tomorrow unless
someone else has already done it by then.


[Bug rtl-optimization/64156] Subversion id 218266 breaks the big-endian 64-bit PowerPC build (wilco.dijks...@arm.com's mod to ira-costs.c)

2014-12-02 Thread vmakarov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64156

--- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Wilco from comment #3)
 
 Anyway it looks like this patch has triggered some complex allocation
 issues, so it seems best to revert it. I'll get someone to do that tomorrow
 unless someone else has already done it by then.

Yes, it is better to revert the patch, Wilco.  The fixing a problem in reload
(and ppc uses reload by default) is very tricky.  It can take long time (might
be weeks) to fix it even if you have a big expertise in reload pass.  So there
is no real solution besides reverting the patch.