[Bug target/36223] IV-opt is not optimal for mips

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-08-25 00:37 
---
I tweaked IVOPTS a few months ago to help in similar cases on PowerPC:

2009-05-29  Eric Botcazou  

* tree-ssa-loop-ivopts.c (strip_offset_1) : New case.
(force_expr_to_var_cost) : Likewise.
(ptr_difference_cost): Use affine combinations to compute it.
(difference_cost): Likewise.
(get_computation_cost_at): Compute more accurate cost for addresses
if the ratio is a multiplier allowed in addresses.
For non-addresses, consider that an additional offset or symbol is
added only once.

Maybe this helped for MIPS in this case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223

[Bug target/36223] IV-opt is not optimal for mips

[sandra at codesourcery dot com]

--- Comment #6 from sandra at codesourcery dot com  2009-08-24 22:36 ---
This bug appears to be fixed in mainline HEAD now.  Here's an excerpt showing
the generated code for the inner loop in the example program now:

addiu   $21,$28,%gp_rel(AA)
addiu   $10,$28,%gp_rel(A)
addiu   $20,$28,%gp_rel(BB)
addiu   $9,$28,%gp_rel(B)
li  $19,2044# 0x7fc
li  $18,10  # 0xa
move$2,$0
.L3:
addu$8,$10,$2
addu$3,$9,$2
lw  $24,0($8)
addu$14,$21,$2
lw  $8,0($3)
addu$3,$20,$2
addiu   $2,$2,4
sw  $24,0($14)
bne $2,$19,.L3
sw  $8,0($3)

All 4 gp_rel address computations pulled outside the loop, and only 5 adds
inside.  I'm not sure what fixed this, but it does seem fixed.


-- 

sandra at codesourcery dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223

[Bug target/36223] IV-opt is not optimal for mips

[sandra at codesourcery dot com]

--- Comment #5 from sandra at codesourcery dot com  2008-06-30 02:05 ---
Maybe I'm just being clueless here, but I don't understand why this bug was
re-categorized.  In my original analysis, I traced the bad code directly to the
RA pass un-doing the results of previous optimizations.  Andrew, if you think
it is going wrong somewhere else, can you provide more details as to where, and
what code you think ought to be coming out of that pass that isn't?  I could
perhaps chew on this some more if I knew what to look for.


-- 

sandra at codesourcery dot com changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223

[Bug target/36223] IV-opt is not optimal for mips

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-06-02 23:11 ---
n


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223

[Bug target/36223] IV-opt is not optimal for mips

[sandra at codesourcery dot com]

--- Comment #3 from sandra at codesourcery dot com  2008-05-12 19:10 ---
One other tidbit:  the MIPS SDE 3.4.4-based toolchain produced the desired code
for this test case.  It's really a 4.* regression, not an enhancement.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223

[Bug target/36223] IV-opt is not optimal for mips

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-12 19:09 ---
Actually this is an IV-opt issue rather than a RA/PRE issue.
For GCC 4.1.1 targeting an internal PPC port, I get the following on the tree
level at the end:
:;
  D.2011 = (long int *) ivtmp.92;
  MEM[base: &AA, index: D.2011] = MEM[base: &A, index: D.2011];
  MEM[base: &BB, index: D.2011] = MEM[base: &B, index: D.2011];
  ivtmp.92 = ivtmp.92 + 4B;
  if (ivtmp.92 != 2044B) goto ; else goto ;

Which should show that this is IV-opts issue rather than a PRE issue at all.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|target
Summary|bad interaction between |IV-opt is not optimal for
   |PRE/register|mips
   |allocation/reload   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223