* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
@ 2013-12-13 10:56 ` rguenth at gcc dot gnu.org
2013-12-13 13:54 ` vries at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-13 10:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
Target Milestone|--- |4.8.3
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
2013-12-13 10:56 ` [Bug rtl-optimization/59477] " rguenth at gcc dot gnu.org
@ 2013-12-13 13:54 ` vries at gcc dot gnu.org
2013-12-19 15:41 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: vries at gcc dot gnu.org @ 2013-12-13 13:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-12-13
CC| |vries at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from vries at gcc dot gnu.org ---
I could reproduce this.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
2013-12-13 10:56 ` [Bug rtl-optimization/59477] " rguenth at gcc dot gnu.org
2013-12-13 13:54 ` vries at gcc dot gnu.org
@ 2013-12-19 15:41 ` rguenth at gcc dot gnu.org
2014-01-02 11:17 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-19 15:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (2 preceding siblings ...)
2013-12-19 15:41 ` rguenth at gcc dot gnu.org
@ 2014-01-02 11:17 ` jakub at gcc dot gnu.org
2014-01-02 15:45 ` ebotcazou at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-02 11:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
CC| |ebotcazou at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r175063, but I guess that just made the problem no longer latent.
More reduced testcase:
struct A
{
unsigned *a, b;
A (unsigned x) : a (), b (x) {}
};
struct B
{
B (int);
B (const B &) {}
};
B bar (B, B, A);
int v;
void
foo ()
{
B c = 0;
bar (c, c, A (1ULL << v));
}
I don't think this is a RA bug, the problem is I think that combine changes:
(insn 20 19 21 2 (set (reg:DI 2 cx)
(const_int 0 [0])) pr59477.C:20 62 {*movdi_internal_rex64}
(nil))
-(insn 21 20 22 2 (set (reg:SI 37 r8)
- (subreg:SI (reg:DI 64) 0)) pr59477.C:20 64 {*movsi_internal}
- (expr_list:REG_DEAD (reg:DI 64)
- (nil)))
+(insn 21 20 22 2 (parallel [
+ (set (reg:DI 37 r8)
+ (ashift:DI (reg:DI 65)
+ (subreg:QI (reg:SI 63 [ v ]) 0)))
+ (clobber (reg:CC 17 flags))
+ ]) pr59477.C:20 503 {*ashldi3_1}
+ (expr_list:REG_UNUSED (reg:CC 17 flags)
+ (expr_list:REG_DEAD (reg:SI 63 [ v ])
+ (expr_list:REG_DEAD (reg:DI 65)
+ (nil)))))
and thus moves a complex operation (which in this case will need %ecx register)
to a place where hard regs need to be live across that and thus makes it hard
for RA to do it's job.
Usually combiner will reject such combination on i?86/x86_64 in the fn argument
hard reg setup insns because of cant_combine_insn_p, but here r8 isn't likely
spilled. Also, typically cx is initialized after r8, because hard register
arguments are initialized from last argument to first. But in this case there
is one argument passed in rcx/r8 pair and within a single argument we typically
initialize the first half before the second one.
As no arguments are passed in more than two hard registers, supposedly
the rcx/r8 case is the only problematic one for function arguments, so perhaps
ix86_legitimate_combined_insn could if the output is hard register r8 look for
previous insn if it sets rcx and in that case reject the combination.
In general, e.g. for local register asm variables (e.g. as used for various
syscall inline asm wrappers etc.), I wonder if it isn't unsafe to combine
anything across instructions that set likely spilled hard registers, so perhaps
alternative would be to take that into account when creating LOG_LINKS in
create_log_links. As clearing the whole next_use array upon seeing
if (HARD_REGISTER_NUM_P (regno)
&& ! TEST_HARD_REG_BIT (fixed_reg_set, regno)
&& targetm.class_likely_spilled_p (REGNO_REG_CLASS (regno)))
early in the
for (def_vec = DF_INSN_DEFS (insn); *def_vec; def_vec++)
loop might be too expensive, perhaps we'd need to add another array with a tick
count when next_use was set and increment the tick count on the above mentioned
condition, and consider uses with tick count smaller than the current one as
next_use[] == NULL.
Thoughts on this?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (3 preceding siblings ...)
2014-01-02 11:17 ` jakub at gcc dot gnu.org
@ 2014-01-02 15:45 ` ebotcazou at gcc dot gnu.org
2014-01-02 16:02 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-01-02 15:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Usually combiner will reject such combination on i?86/x86_64 in the fn
> argument hard reg setup insns because of cant_combine_insn_p, but here r8
> isn't likely spilled. Also, typically cx is initialized after r8, because
> hard register arguments are initialized from last argument to first. But in
> this case there is one argument passed in rcx/r8 pair and within a single
> argument we typically initialize the first half before the second one.
Is rcx likely spilled? If so, the situation looks similar to the one dealt
with by likely_spilled_retval_p so maybe the machinery could be extended to
argument registers.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (4 preceding siblings ...)
2014-01-02 15:45 ` ebotcazou at gcc dot gnu.org
@ 2014-01-02 16:02 ` jakub at gcc dot gnu.org
2014-01-02 16:50 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-02 16:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #4)
> > Usually combiner will reject such combination on i?86/x86_64 in the fn
> > argument hard reg setup insns because of cant_combine_insn_p, but here r8
> > isn't likely spilled. Also, typically cx is initialized after r8, because
> > hard register arguments are initialized from last argument to first. But in
> > this case there is one argument passed in rcx/r8 pair and within a single
> > argument we typically initialize the first half before the second one.
>
> Is rcx likely spilled? If so, the situation looks similar to the one dealt
> with by likely_spilled_retval_p so maybe the machinery could be extended to
> argument registers.
Yes, rcx is likely spilled, just r8 isn't and there is rcx = 0; r8 = pseudo1;
in that order before combine and combine is changing it to rcx = 0; r8 =
pseudo2 << pseudo3;
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (5 preceding siblings ...)
2014-01-02 16:02 ` jakub at gcc dot gnu.org
@ 2014-01-02 16:50 ` jakub at gcc dot gnu.org
2014-01-15 14:52 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-02 16:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
A problem with doing this in create_log_links with a simpler tick counter might
be that it would prevent any combination across most of the CALL_INSNs.
Dunno how often that happens in practice though.
So perhaps for calls we'd need to do something smarter, like if we see a
CALL_INSN, look at CALL_INSN_FUNCTION_USAGE and if there are any likely spilled
regs used for arguments or return value, try to find the range of insns between
last copying of return value reg (if likely spilled) into pseudo(s), or
CALL_INSN if not returning value or return value is not likely spilled, and
first insn to set up call argument in likely spilled argument. We could then
treat the whole range of insns as a range that clears next_use rather than
setting it to insns in that range, and ignore the above mentioned special
handling of likely spilled hard reg setters in that range.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (6 preceding siblings ...)
2014-01-02 16:50 ` jakub at gcc dot gnu.org
@ 2014-01-15 14:52 ` jakub at gcc dot gnu.org
2014-01-22 19:39 ` vmakarov at gcc dot gnu.org
2014-01-22 21:02 ` [Bug rtl-optimization/59477] [4.8 " law at redhat dot com
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-15 14:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31844
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31844&action=edit
gcc49-pr59477.patch
Untested fix.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (7 preceding siblings ...)
2014-01-15 14:52 ` jakub at gcc dot gnu.org
@ 2014-01-22 19:39 ` vmakarov at gcc dot gnu.org
2014-01-22 21:02 ` [Bug rtl-optimization/59477] [4.8 " law at redhat dot com
9 siblings, 0 replies; 11+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2014-01-22 19:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Wed Jan 22 19:38:47 2014
New Revision: 206938
URL: http://gcc.gnu.org/viewcvs?rev=206938&root=gcc&view=rev
Log:
2014-01-22 Vladimir Makarov <vmakarov@redhat.com>
PR rtl-optimization/59477
* lra-constraints.c (inherit_in_ebb): Process call for living hard
regs. Update reloads_num and potential_reload_hard_regs for all
insns.
2014-01-22 Vladimir Makarov <vmakarov@redhat.com>
PR rtl-optimization/59477
* g++.dg/pr59477.C: New.
Added:
trunk/gcc/testsuite/g++.dg/pr59477.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/59477] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
2013-12-11 21:44 [Bug rtl-optimization/59477] New: [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O zsojka at seznam dot cz
` (8 preceding siblings ...)
2014-01-22 19:39 ` vmakarov at gcc dot gnu.org
@ 2014-01-22 21:02 ` law at redhat dot com
9 siblings, 0 replies; 11+ messages in thread
From: law at redhat dot com @ 2014-01-22 21:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |law at redhat dot com
Resolution|--- |FIXED
--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
Fixed by Vlad's commit on the trunk.
^ permalink raw reply [flat|nested] 11+ messages in thread