public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/64226] New: Secondary reload incorrect TOC address
@ 2014-12-08 16:00 dje at gcc dot gnu.org
2014-12-08 16:03 ` [Bug target/64226] [5.0 Regression] " dje at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: dje at gcc dot gnu.org @ 2014-12-08 16:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
Bug ID: 64226
Summary: Secondary reload incorrect TOC address
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Many of the GCC testsuite VMX tests fail on AIX because secondary reload is
generating an incorrect TOC reference. A MEM is being stripped from a
TOC reference causing GCC to use a pattern for a raw address,
generating a bogus reference.
226r.ira:
(insn 347 346 348 8 (set (reg/f:SI 489)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI ("*LC..32") [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8])) ld.c:83 411 {*movsi_internal1}
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*LC..31") [flags 0x2])
(nil)))
(insn 348 347 349 8 (set (reg:V8HI 488)
(mem/u/c:V8HI (reg/f:SI 489) [0 S16 A128])) ld.c:83 972
{*altivec_movv8
hi}
(expr_list:REG_DEAD (reg/f:SI 489)
(expr_list:REG_EQUIV (const_vector:V8HI [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
])
(nil))))
(insn 349 348 350 8 (parallel [
(set (reg:CC 74 6)
(unspec:CC [
(eq:CC (reg:V8HI 456)
(reg:V8HI 488))
] UNSPEC_PREDICATE))
(set (reg:V8HI 490)
(eq:V8HI (reg:V8HI 456)
(reg:V8HI 488)))
]) ld.c:83 1206 {*altivec_vcmpequh_p}
(expr_list:REG_DEAD (reg:V8HI 456)
(expr_list:REG_UNUSED (reg:V8HI 490)
(nil))))
227r.reload:
Reloads for insn # 349
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
BASE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1), can't combine
reload_in_reg: (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
reload_reg_rtx: (reg:SI 7 7)
Reload 1: reload_in (SI) = (symbol_ref/u:SI ("*LC..31") [flags 0x2])
BASE_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 2)
reload_in_reg: (symbol_ref/u:SI ("*LC..31") [flags 0x2])
reload_reg_rtx: (reg/f:SI 9 9 [489])
Reload 2: reload_in (V8HI) = (mem/c:V8HI (plus:SI (reg/f:SI 1 1)
(const_int 96 [0x60]))
[
0 %sfp+96 S16 A128])
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (reg:V8HI 456)
reload_reg_rtx: (reg:V8HI 78 1)Reload 3: BASE_REGS,
RELOAD_FOR_INPUT_ADDRESS (opnum = 2), can't combine, second
ary_reload_p
reload_reg_rtx: (reg:SI 7 7)
Reload 4: reload_in (V8HI) = (mem/u/c:V8HI (symbol_ref/u:SI ("*LC..31") [flags
0
x2]) [0 S16 A128])
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 2), can't combine
reload_in_reg: (reg:V8HI 488)
reload_reg_rtx: (reg:V8HI 90 13)
secondary_in_reload = 3
secondary_in_icode = reload_v8hi_si_load
(insn 498 497 499 8 (set (reg:SI 7 7)
(unspec:SI [
(symbol_ref/u:SI ("*LC..31") [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL)) ld.c:83 532 {*tocrefsi}
(nil))
(insn 499 498 349 8 (set (reg:V8HI 90 13)
(mem/u/c:V8HI (reg:SI 7 7) [0 S16 A128])) ld.c:83 972
{*altivec_movv8hi
}
(nil))
(insn 349 499 350 8 (parallel [
(set (reg:CC 74 6)
(unspec:CC [
(eq:CC (reg:V8HI 78 1)
(reg:V8HI 90 13))
] UNSPEC_PREDICATE))
(set (reg:V8HI 77 0 [490])
(eq:V8HI (reg:V8HI 78 1)
(reg:V8HI 90 13)))
]) ld.c:83 1206 {*altivec_vcmpequh_p}
(nil))
Pseudo 489 was loaded with (mem:SI (unspec:SI [LC..32]
TOCREL)) but r7 is loaded directly with (unspec:SI [LC..31] TOCREL).
I assume that find_replacement is finding symbol_ref LC..31 and using
that. There is no valid way to reference LC..31 directly on AIX.
It's clearer with -fno-section-anchors. LC..31 is in read-only data:
.csect _ld.rw_[RO],4
.align 4
...
LC..31:
.short 0
.short 1
.short 2
.short 3
.short 4
.short 5
.short 6
.short 7
LC..32 would have been a TOC reference to LC..31
.toc
LC..32:
.tc LC..31[TC],LC..31
but that is deleted and replaced with a direct reference to the RO
data. The final instruction stream is
addi 7,1,96
lvx 1,0,7
la 7,LC..31(2) <-----
lvx 13,0,7
vcmpequh. 0,1,13
lwz 4,LC..34(2)
mfcr 3
rlwinm 3,3,25,1
bl .check
which tries to load the RO data directly and use LC..31 as a TOC displacement.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
2014-12-08 16:00 [Bug target/64226] New: Secondary reload incorrect TOC address dje at gcc dot gnu.org
@ 2014-12-08 16:03 ` dje at gcc dot gnu.org
2014-12-08 16:17 ` dje at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: dje at gcc dot gnu.org @ 2014-12-08 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
David Edelsohn <dje at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-08
CC| |meissner at gcc dot gnu.org,
| |uweigand at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|Secondary reload incorrect |[5.0 Regression] Secondary
|TOC address |reload incorrect TOC
| |address
Ever confirmed|0 |1
--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
2014-12-08 16:00 [Bug target/64226] New: Secondary reload incorrect TOC address dje at gcc dot gnu.org
2014-12-08 16:03 ` [Bug target/64226] [5.0 Regression] " dje at gcc dot gnu.org
@ 2014-12-08 16:17 ` dje at gcc dot gnu.org
2014-12-08 23:48 ` dje at gcc dot gnu.org
2014-12-08 23:49 ` dje at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dje at gcc dot gnu.org @ 2014-12-08 16:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
--- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> ---
Uli mentioned in private email:
"I think the piece of code quoted above from rs6000_secondary_reload_inner
is wrong; it should not call create_TOC_reference unconditionally.
"Other places that use TOC-relative addressing first verify whether the
symbol actually supports that, using use_toc_relative_ref. So this
check should probably be done here too. If a symbol cannot be accessed
via TOC-relative addressing, we should call rs6000_emit_move, which
should do the right thing (forcing the address into the TOC)."
And the following patch to remove the special call to create_TOC_reference
seems to fix the problem.
Index: rs6000.c
===================================================================
--- rs6000.c (revision 218484)
+++ rs6000.c (working copy)
@@ -17379,12 +17379,7 @@
case SYMBOL_REF:
case CONST:
case LABEL_REF:
- if (TARGET_TOC)
- emit_insn (gen_rtx_SET (VOIDmode, scratch,
- create_TOC_reference (addr, scratch)));
- else
- rs6000_emit_move (scratch, addr, Pmode);
-
+ rs6000_emit_move (scratch, addr, Pmode);
new_addr = scratch;
break;
I am testing bootstrap.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
2014-12-08 16:00 [Bug target/64226] New: Secondary reload incorrect TOC address dje at gcc dot gnu.org
2014-12-08 16:03 ` [Bug target/64226] [5.0 Regression] " dje at gcc dot gnu.org
2014-12-08 16:17 ` dje at gcc dot gnu.org
@ 2014-12-08 23:48 ` dje at gcc dot gnu.org
2014-12-08 23:49 ` dje at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dje at gcc dot gnu.org @ 2014-12-08 23:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
--- Comment #3 from David Edelsohn <dje at gcc dot gnu.org> ---
Author: dje
Date: Mon Dec 8 23:47:39 2014
New Revision: 218497
URL: https://gcc.gnu.org/viewcvs?rev=218497&root=gcc&view=rev
Log:
PR target/64226
* config/rs6000/rs6000.c (rs6000_secondary_reload_inner)
[SYMBOL_REF]: Do not explicitly call create_TOC_reference for
TARGET_TOC. Always use rs6000_emit_move.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
2014-12-08 16:00 [Bug target/64226] New: Secondary reload incorrect TOC address dje at gcc dot gnu.org
` (2 preceding siblings ...)
2014-12-08 23:48 ` dje at gcc dot gnu.org
@ 2014-12-08 23:49 ` dje at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dje at gcc dot gnu.org @ 2014-12-08 23:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
David Edelsohn <dje at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from David Edelsohn <dje at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-12-08 23:49 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-08 16:00 [Bug target/64226] New: Secondary reload incorrect TOC address dje at gcc dot gnu.org
2014-12-08 16:03 ` [Bug target/64226] [5.0 Regression] " dje at gcc dot gnu.org
2014-12-08 16:17 ` dje at gcc dot gnu.org
2014-12-08 23:48 ` dje at gcc dot gnu.org
2014-12-08 23:49 ` dje at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).