[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-08-02 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

--- Comment #5 from Kazumoto Kojima  2011-08-02 
23:53:30 UTC ---
I was trying to find a way that solves it without penalizing -O2
or the higher cases, though it's not easy to me.  It seems that
the target's register_move_cost is the way to discourage trying
to use FP registers for a pointer.  Unfortunately, Pmode is simply
SImode for our case and it also discourages using a FP reg as
a cheap storage for SImode.  I've tried

--- ORIG/trunk/gcc/config/sh/sh.c2011-08-01 09:22:27.0 +0900
+++ trunk/gcc/config/sh/sh.c2011-08-01 09:41:25.0 +0900
@@ -11472,8 +11472,18 @@ sh_register_move_cost (enum machine_mode
&& REGCLASS_HAS_GENERAL_REG (srcclass))
   || (REGCLASS_HAS_GENERAL_REG (dstclass)
   && REGCLASS_HAS_FP_REG (srcclass)))
-return ((TARGET_SHMEDIA ? 4 : TARGET_FMOVD ? 8 : 12)
-* ((GET_MODE_SIZE (mode) + 7) / 8U));
+{
+  if (TARGET_SHMEDIA)
+return 4 * ((GET_MODE_SIZE (mode) + 7) / 8U);
+  else
+{
+  /* Discourage trying to use fp regs for a pointer.  */
+  int addend = (mode == Pmode) ? 40 : 0;
+
+  return (((TARGET_FMOVD ? 8 : 12) + addend)
+  * ((GET_MODE_SIZE (mode) + 7) / 8U));
+}
+}

   if ((dstclass == FPUL_REGS
&& REGCLASS_HAS_GENERAL_REG (srcclass))

on the current trunk and observed some CSiBE testresults.  A bit
surprisingly, there are no code size regressions and one 2%
improvement for teem-1.6.0-src src/bane/gkmsTxf which reduces
to 3192 bytes from 3256 bytes.  Now I'm inclined to apply it
on trunk if it passes the bootstrap/regression/other tests.


[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-08-02 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.08.02 14:00:23
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther  2011-08-02 
14:00:23 UTC ---
Any updates?


[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-08-01 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0


[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-04-22 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #3 from Kazumoto Kojima  2011-04-23 
00:06:46 UTC ---
I'd like to add Vlad to the cc list.

I've tried to avoid allocating FP register to r242 with changing
target setting.  Increasing move_cost between integer and floating
registers looks to work.  With changing current cost 12 to 34, .ira
reports the same costs at -O2

  a20(r242,l1) costs: R0_REGS:0,0 FPUL_REGS:305,305 SIBCALL_REGS:0,0
GENERAL_REGS:0,0 FP0_REGS:3892,3892 FP_REGS:3892,3892 DF_HI_REGS:3892,3892
DF_REGS:3892,3892 GENERAL_FP_REGS:6619,6619 GENERAL_DF_REGS:6619,6619
ALL_REGS:6619,6619 MEM:3880,3880

and r7 is allocated to r242 like as -O2.
I hope that these numbers say something meaningful for experts.


[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-04-18 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

--- Comment #2 from Kazumoto Kojima  2011-04-18 
12:47:21 UTC ---
I'm looking into why fr14 is allocated to r242 when -O1 is specified.
Here is the info about r242 from .ira dump with -O1

r242: preferred GENERAL_REGS, alternative GENERAL_FP_REGS, allocno
GENERAL_FP_REGS
a20 (r242,l1) best GENERAL_REGS, allocno GENERAL_FP_REGS
...
  a20(r242,l1) costs: R0_REGS:0,0 FPUL_REGS:305,305 SIBCALL_REGS:0,0
GENERAL_REGS:0,0 FP0_REGS:2550,2550 FP_REGS:2550,2550 DF_HI_REGS:2550,2550
DF_REGS:2550,2550 GENERAL_FP_REGS:5277,5277 GENERAL_DF_REGS:5277,5277
ALL_REGS:5277,5277 MEM:3880,3880

In contrast, r242 gets GENERAL_REGS for allocno with -O2

r242: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
a20 (r242,l1) best GENERAL_REGS, allocno GENERAL_REGS
...
  a20(r242,l1) costs: R0_REGS:0,0 FPUL_REGS:305,305 SIBCALL_REGS:0,0
GENERAL_REGS:0,0 FP0_REGS:3892,3892 FP_REGS:3892,3892 DF_HI_REGS:3892,3892
DF_REGS:3892,3892 GENERAL_FP_REGS:6619,6619 GENERAL_DF_REGS:6619,6619
ALL_REGS:6619,6619 MEM:3880,3880

and for revision 171582 with -O1

r242: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
a20 (r242,l1) best GENERAL_REGS, cover GENERAL_REGS
...
  a20(r242,l1) costs: R0_REGS:0,0 SIBCALL_REGS:0,0 GENERAL_REGS:0,0
FP0_REGS:2550,2550 FP_REGS:2550,2550 FPUL_REGS:305,305 MEM:3880

With -O1, the lines 1713-1714 of ira-costs.c set allocno to
GENERAL_FP_REGS in this case

1707  if (best_cost > i_mem_cost)
1708regno_aclass[i] = NO_REGS;
1709  else
1710{
1711  /* Make the common class the biggest class of best and
1712 alt_class.  */
1713  regno_aclass[i]
1714= ira_reg_class_superunion[best][alt_class];

Is there any way to notify IRA that the alt_class will be too costy
in some cases?


[Bug rtl-optimization/48596] [4.7 Regression] [SH] unable to find a register to spill in class 'FPUL_REGS'

2011-04-13 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596

Kazumoto Kojima  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||sh-*-*
  Known to work||4.6.0
  Known to fail||4.7.0

--- Comment #1 from Kazumoto Kojima  2011-04-13 
22:47:25 UTC ---
It started to fail between revisions 171582 and 171649.

.ira dump says

Spilling for insn 105.
Using reg 150 for reload 0
reload failure for reload 3

Reloads for insn # 105
Reload 0: FPUL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
Reload 1: reload_in (SI) = (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242])
GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242])
secondary_in_reload = 0
Reload 2: GENERAL_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
Reload 3: reload_out (SI) = (mem:SI (reg/f:SI 78 fr14 [orig:242 D.2027 ] [242])
[0 MEM[(struct Info *)D.2027_55]+0 S4 A32])
FPUL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg:SI 264)
secondary_out_reload = 2

It looks odd to choose floating point register fr14 for a memory address.