* Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
@ 2009-07-30 14:32 Joern Rennecke
0 siblings, 0 replies; 5+ messages in thread
From: Joern Rennecke @ 2009-07-30 14:32 UTC (permalink / raw)
To: Andrew Stubbs; +Cc: Ian Lance Taylor, gcc
> This is then transformed by subst_reloads to the final broken form:
>
> (insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
> (plus:SI (reg:SI 8 r8)
> (reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))
>
> This is logically correct as r9 genuinely does contain the result of the
> substituted expression, but it does not satisfy the constraints.
>
> And here's where I get stuck. I don't know where in the code it's
> supposed to check that the code will be correct after the substitution.
>
> The (plus (plus ...) ...) rtl is generated by
> find_reloads_subreg_address using make_memloc and plus_constant, and it
> seems correct in itself.
This used to be 'handled' by reload register allocation which would
use the same reload register for RELOAD_FOR_INPUT_ADDRESS as for
RELOAD_FOR_INPADDR_ADDREESS if both are for the same operand.
It is strange that you have two RELOAD_FOR_INPUT_ADDRESS reloads
instead.
Although, in terms of ensuring correctness, it would be saner if
gen_reload would make sure it generates valid code even for unusual
reload register allocations.
Unfortunately, that'll require it to make a guess if a two-address add
is required; you can scan the insn pattern for matching constraints, but
that is somewhat hit-and-miss (obviously you can't use constrain_operands
there unless you want to save / restore all the extraction data); you'll
end up generating some unneeded register-register moves on some
architectures. But you could make sure they get removed in postreload.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
2009-07-09 18:12 ` Ian Lance Taylor
@ 2009-07-30 8:27 ` Andrew Stubbs
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Stubbs @ 2009-07-30 8:27 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
On 09/07/09 19:11, Ian Lance Taylor wrote:
> Andrew Stubbs<ams@codesourcery.com> writes:
>
>> The problem insn is created by gen_reload when it is given the
>> following rtl as input:
>>
>> (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
>> (const_int 2 [0x2]))
>> (reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))
>
> You need to backtrack before that point to see why find_reloads let that
> go through.
OK, I've gone through it all trying to understand it, but this is fairly
complex code and I don't claim to get it.
Here's my analysis of the problem.
The problem instruction in pr34330.c.181r.sched1 (the state before
register allocation/reload) is:
(insn 97 103 111 5 .../pr34330.c:17 (set (mem/s:HI (reg/f:SI 239 [
D.1960 ]) [6 D.1960_8->s1+0 S2 A16])
(subreg:HI (reg:SI 257) 2)) 187 {movhi_i} (expr_list:REG_DEAD
(reg:SI 257)
(nil)))
The reloads for this instruction are:
Reloads for insn # 97
Reload 0: reload_in (SI) = (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
reload_reg_rtx: (reg:SI 8 r8)
Reload 1: reload_in (SI) = (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250
a ] [250])
(const_int 2
[0x2]))
(reg:SI 0 r0
[orig:243 ivtmp.11 ] [243]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ]
[250])
(const_int 2
[0x2]))
(reg:SI 0 r0
[orig:243 ivtmp.11 ] [243]))
reload_reg_rtx: (reg:SI 9 r9)
Reload 2: reload_out (HI) = (mem/s:HI (reg/f:SI 2 r2 [orig:239 D.1960 ]
[239]) [6 D.1960_8->s1+0 S2 A16])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/s:HI (reg/f:SI 2 r2 [orig:239 D.1960 ]
[239]) [6 D.1960_8->s1+0 S2 A16])
Reload 3: reload_in (HI) = (mem:HI (plus:SI (plus:SI (reg/v/f:SI 4 r4
[orig:250 a ] [250])
(const_int
2 [0x2]))
(reg:SI 0 r0
[orig:243 ivtmp.11 ] [243])) [3 S4 A32])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (subreg:HI (reg:SI 257) 2)
reload_reg_rtx: (reg:HI 8 r8)
Which results in this instruction sequence in pr34330.c.183r.ira:
(insn 169 103 170 4 .../pr34330.c:17 (set (reg:SI 8 r8)
(const_int 2 [0x2])) 175 {movsi_ie} (nil))
(insn 170 169 171 4 .../pr34330.c:17 (set (reg:SI 8 r8)
(plus:SI (reg:SI 8 r8)
(reg/v/f:SI 4 r4 [orig:250 a ] [250]))) 35
{*addsi3_compact} (expr_list:REG_EQUIV (plus:SI (reg/v/f:SI 4 r4
[orig:250 a ] [250])
(const_int 2 [0x2]))
(nil)))
(insn 171 170 172 4 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35
{*addsi3_compact} (nil))
(insn 172 171 97 4 .../pr34330.c:17 (set (reg:HI 8 r8)
(mem:HI (reg:SI 9 r9) [3 S4 A32])) 187 {movhi_i} (nil))
(insn 97 172 111 4 .../pr34330.c:17 (set (mem/s:HI (reg/f:SI 2 r2
[orig:239 D.1960 ] [239]) [6 D.1960_8->s1+0 S2 A16])
(reg:HI 8 r8)) 187 {movhi_i} (nil))
The problem is in insn 171 where r9 != r8 and therefore cannot match an
SH 2-operand add instruction.
Looking back at how this happens, insn 171 is created by gen_reload from
reload #1 and initially looks like this:
(insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:250 a ] [250])
(const_int 2 [0x2]))
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))
This is then transformed by subst_reloads to the final broken form:
(insn 171 170 172 5 .../pr34330.c:17 (set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) -1 (nil))
This is logically correct as r9 genuinely does contain the result of the
substituted expression, but it does not satisfy the constraints.
And here's where I get stuck. I don't know where in the code it's
supposed to check that the code will be correct after the substitution.
The (plus (plus ...) ...) rtl is generated by
find_reloads_subreg_address using make_memloc and plus_constant, and it
seems correct in itself.
Any help would be appreciated.
Thanks
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
2009-07-09 11:54 Andrew Stubbs
2009-07-09 18:12 ` Ian Lance Taylor
@ 2009-07-15 6:39 ` Maxim Kuvyrkov
1 sibling, 0 replies; 5+ messages in thread
From: Maxim Kuvyrkov @ 2009-07-15 6:39 UTC (permalink / raw)
To: Andrew Stubbs; +Cc: gcc
Andrew Stubbs wrote:
> I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
>
> Given the following command:
>
> cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
> -auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
> -ftree-vectorize -o pr34330.s -fschedule-insns
>
> I get an internal compiler error:
>
> GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
> compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version
> 2.4.1-p5, MPC version 0.6
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
> compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR version
> 2.4.1-p5, MPC version 0.6
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Compiler executable checksum: c91a929a0209c0670a3ae8b8067b9f9a
> /scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:
> In function 'foo':
> /scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
> error: insn does not satisfy its constraints:
> (insn 171 170 172 4
> /scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:17
> (set (reg:SI 9 r9)
> (plus:SI (reg:SI 8 r8)
> (reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35
> {*addsi3_compact} (nil))
> /scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
> internal compiler error: in reload_cse_simplify_operands, at
> postreload.c:396
This looks much like PR37053 on m68k/ColdFire; the easiest way to check
if this ICE was caused by the same error is to revert hunk in rtlanal.c:
commutative_operand_precedence() -- see in the PR.
As to the fix, there are several patches being discussed here
(http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00816.html) and here
(http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00823.html).
My $0.02.
--
Maxim
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
2009-07-09 11:54 Andrew Stubbs
@ 2009-07-09 18:12 ` Ian Lance Taylor
2009-07-30 8:27 ` Andrew Stubbs
2009-07-15 6:39 ` Maxim Kuvyrkov
1 sibling, 1 reply; 5+ messages in thread
From: Ian Lance Taylor @ 2009-07-09 18:12 UTC (permalink / raw)
To: Andrew Stubbs; +Cc: gcc
Andrew Stubbs <ams@codesourcery.com> writes:
> The problem insn is created by gen_reload when it is given the
> following rtl as input:
>
> (plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
> (const_int 2 [0x2]))
> (reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))
You need to backtrack before that point to see why find_reloads let that
go through.
Ian
^ permalink raw reply [flat|nested] 5+ messages in thread
* [SH] ICE compiling pr34330 testcase for sh-linux-gnu
@ 2009-07-09 11:54 Andrew Stubbs
2009-07-09 18:12 ` Ian Lance Taylor
2009-07-15 6:39 ` Maxim Kuvyrkov
0 siblings, 2 replies; 5+ messages in thread
From: Andrew Stubbs @ 2009-07-09 11:54 UTC (permalink / raw)
To: gcc
I'm having trouble with an ICE, and I'm hoping somebody can enlighten me.
Given the following command:
cc1 -fpreprocessed ../pr34330.i -quiet -dumpbase pr34330.c -da -mb
-auxbase-strip pr34330.c -Os -version -ftree-parallelize-loops=4
-ftree-vectorize -o pr34330.s -fschedule-insns
I get an internal compiler error:
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR
version 2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20090702 (experimental) (sh-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.1, MPFR
version 2.4.1-p5, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c91a929a0209c0670a3ae8b8067b9f9a
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:
In function 'foo':
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
error: insn does not satisfy its constraints:
(insn 171 170 172 4
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:17
(set (reg:SI 9 r9)
(plus:SI (reg:SI 8 r8)
(reg:SI 0 r0 [orig:243 ivtmp.11 ] [243]))) 35
{*addsi3_compact} (nil))
/scratch/ams/4.4-sh-linux-gnu-lite/src/gcc-trunk-4.4/gcc/testsuite/gcc.dg/torture/pr34330.c:22:1:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
The problem is that r8 != r9 but SH requires that it is.
The problem insn is created by gen_reload when it is given the following
rtl as input:
(plus:SI (plus:SI (reg/v/f:SI 4 r4 [orig:192 a ] [192])
(const_int 2 [0x2]))
(reg:SI 0 r0 [orig:188 ivtmp.24 ] [188]))
The problem appears to be that the nested plus does not match any of the
patterns it recognizes so it falls through to the final else clause:
/* Otherwise, just write (set OUT IN) and hope for the best. */
else
emit_insn (gen_rtx_SET (VOIDmode, out, in));
... which doesn't even attempt to check the constraints.
Is this an unexpected corner case for reload? Or is the input RTL
mal-formed somehow?
This case fails in both GCC 4.4 and SVN trunk (although the latter has
disabled -fschedule-insns by default so it needs to be re-enabled
explicitly).
Thanks for an help.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-07-30 14:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-30 14:32 [SH] ICE compiling pr34330 testcase for sh-linux-gnu Joern Rennecke
-- strict thread matches above, loose matches on Subject: below --
2009-07-09 11:54 Andrew Stubbs
2009-07-09 18:12 ` Ian Lance Taylor
2009-07-30 8:27 ` Andrew Stubbs
2009-07-15 6:39 ` Maxim Kuvyrkov
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).