public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* PR target/16482: first scheduling pass on SH4
@ 2004-10-15 10:56 tm_gccmail
  2004-10-15 15:52 ` Kaz Kojima
  0 siblings, 1 reply; 9+ messages in thread
From: tm_gccmail @ 2004-10-15 10:56 UTC (permalink / raw)
  To: kkojima, naveens; +Cc: gcc


Sorry, deleted the original message to which I should be replying, which
screws up the threading, but anyway:

Original message: http://gcc.gnu.org/ml/gcc/2004-10/msg00176.html

Kaz Kojima wrote:

> Thus the first insn scheduling permutes [r4+r161]=r164 into a lifetime
> of R0 and the spill process needs R0 for the expression for [r4+r161]
> because SH-4 uses R0 as the base register for the addressing mode with
> an index register.
>
> Does the first insn scheduling for SH-4 take account of such insn which
> uses R0 implicitly?  Or is it a problem of the reload pass?

The first instruction scheduling pass cannot extend the lifetime of
pseudos which need r0 since there is only one r0 register.

So yes, this sounds like an SH first instruction scheduling pass bug.

Incidentally, I can reproduce the same problem with a small array index
and -fPIC. Compile this with -O2 -mf -fPIC:

int glob1;

adrreg01limm1_set (float *p0)
{
        p0[10] = (float) glob1;
}

test2.c: In function 'adrreg01limm1_set':
test2.c:7: error: unable to find a register to spill in class 'R0_REGS'
test2.c:7: error: this is the insn:
(insn 49 50 18 0 (set (reg/f:SI 1 r1 [162])
        (mem/u:SI (plus:SI (reg:SI 12 r12)
                (reg/f:SI 1 r1 [163])) [0 S4 A32])) 129 {movsi_ie} (nil)
    (expr_list:REG_DEAD (reg/f:SI 1 r1 [163])
        (expr_list:REG_EQUIV (symbol_ref:SI ("glob1") <var_decl 0x401c215c
glob1>)
            (nil))))
test2.c:7: internal compiler error: in spill_failure, at /reload1.c:1881

Toshi

^ permalink raw reply	[flat|nested] 9+ messages in thread
* PR target/16482: first scheduling pass on SH4
@ 2004-10-06 12:23 Kaz Kojima
  0 siblings, 0 replies; 9+ messages in thread
From: Kaz Kojima @ 2004-10-06 12:23 UTC (permalink / raw)
  To: gcc

Hi,

PR target/16482 is a regression for sh-elf from 3.4.  The following
part of gcc.c-torture/unsorted/SFset.c:

int glob1;
 
adrreg0limm1_set (float *p0)
{
  p0[10000000] = (float) glob1;
}

causes a spill failure for sh-elf on mainline with -m4 -O2.
It seems that the first insn scheduling which has been enabled for
SH-4 on mainline badly interacts with reloading.  The .sched file
for the problematic function looks like:

;;   ======================================================
;;   -- basic block 1 from 15 to 35 -- before reload
;;   ======================================================

;;	  0--> 36   r1=`__fpscr_values'                :(issue+load_store),nothing,memory
;;	  0--> 25   clobber r0                         :nothing
;;	  0--> 26   clobber r158                       :nothing
;;	  0--> 24   r0=r158                            :issue
;;	  1--> 17   r163=`glob1'                       :(issue+load_store),nothing,memory
;;	  1--> 27   use r0                             :nothing
;;	  2--> 37   =[r1]                              :d_lock,nothing,(F1+memory),F1*2
;;	  3--> 18   r165=[r163]                        :(issue+load_store),nothing,memory
;;	  4--> 15   r161=0x2625a00                     :(issue+load_store),nothing,memory
;;	  5--> 33   r1=`__fpscr_values'                :(issue+load_store),nothing,memory
;;	  6--> 19   {r164=flt(r165);use ;}             :issue,F01,F2
;;	  7--> 34   r166=r1+0x4                        :issue,int
;;	  8--> 20   {[r4+r161]=r164;use ;clobber scratc:(issue+load_store),nothing,memory
;;	  9--> 35   =[r166]                            :d_lock,nothing,(F1+memory),F1*2
;;	Ready list (final):  
;;   total time = 9
;;   new head = 16
;;   new tail = 35

Thus the first insn scheduling permutes [r4+r161]=r164 into a lifetime
of R0 and the spill process needs R0 for the expression for [r4+r161]
because SH-4 uses R0 as the base register for the addressing mode with
an index register.

Does the first insn scheduling for SH-4 take account of such insn which
uses R0 implicitly?  Or is it a problem of the reload pass?

I've tried to inhibit the permutation like above for the basic blocks
which have insns with [rN+rM] and R0 liftimes.  It works for me, but
what is the right thing to do?

Regards,
	kaz

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-11-05 21:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-15 10:56 PR target/16482: first scheduling pass on SH4 tm_gccmail
2004-10-15 15:52 ` Kaz Kojima
2004-10-29 12:21   ` Alexandre Oliva
2004-10-29 13:30     ` Kaz Kojima
2004-10-29 14:36       ` tm_gccmail
2004-11-04  1:44       ` Kaz Kojima
2004-11-05 16:04         ` Joern RENNECKE
2004-11-05 21:44           ` Kaz Kojima
  -- strict thread matches above, loose matches on Subject: below --
2004-10-06 12:23 Kaz Kojima

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).