public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Stubbs <ams@codesourcery.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [SH] ICE compiling pr34330 testcase for sh-linux-gnu
Date: Thu, 30 Jul 2009 08:27:00 -0000	[thread overview]
Message-ID: <4A715957.8080905@codesourcery.com> (raw)
In-Reply-To: <m3ocrt680t.fsf@google.com>

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

  reply	other threads:[~2009-07-30  8:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09 11:54 Andrew Stubbs
2009-07-09 18:12 ` Ian Lance Taylor
2009-07-30  8:27   ` Andrew Stubbs [this message]
2009-07-15  6:39 ` Maxim Kuvyrkov
2009-07-30 14:32 Joern Rennecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A715957.8080905@codesourcery.com \
    --to=ams@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).