Re: gcc4.5 ivopts question.

[kumon at aa dot mbn dot or dot jp]

Dear Ian, 

Thank you for very informative suggestion.

> The usual way to address this kind of thing is to adjust the
> TARGET_RTX_COSTS hook to return appropriate costs for pointer
> addressing vs. indexed memory addressing.

I checked the TARGET_RTX_COSTS behavior by dumping its arguments for
every call.  There is no indexed addressing case exists.

And I also checked the dump of ivopts pass with
-fdump-tree-ivopts-details flag, I found the following address
calculation cost table.

-----------------------------------------
Addition in PHI costs 12
Address costs:
  index costs 2
  sym + index costs 15
  var + index costs 14
  sym + var + index costs 27
  cst + index costs 18
  sym + cst + index costs 27
  var + cst + index costs 26
  sym + var + cst + index costs 39
  rat * index costs 2
  sym + rat * index costs 15
  var + rat * index costs 14
  sym + var + rat * index costs 27
  cst + rat * index costs 14
  sym + cst + rat * index costs 27
  var + cst + rat * index costs 26
  sym + var + cst + rat * index costs 39
  May include autoinc/dec
-----------------------------------------

Basic my understanding is:

1) Indexed memory addressing, like "MEM[index:ivtmp.7_7]", uses
   "rat * index" cost.

2) Pointer reference addressing, like "MEM[base: d_2]", uses "index"
   cost.  The table is prepared at get_address_cost() in
   tree-ssa-loop-ivopts.c.

I felt strange about the cost of "rat * index", which is same as
bare "index" cost, but it is actually correct. Because, in this case,
the access size is QImode(=byte), that means "rat" == 1.
Multiplication by one is eliminated, the cost becomes exactly same as
cheap "index" cost.

Another problem is that, PHImode is used for "index variable" during
calculation of above table, this differs from the actual RTX.  Usually
index is normal integer (e.g. HImode) and it cannot fit in pointer
register. This causes my problem.

Unfortunately, even if I increased the costs of indexed addressing to
1000 by rewriting the table directly, ivopts doesn't give up using indexed
addressing.

Currently I have no clue to control the ivopts behavior.

---
K.K

From: Ian Lance Taylor <iant@google.com>
Subject: Re: gcc4.5 ivopts question.
Date: Mon, 05 Oct 2009 13:07:14 -0700

> kumon@aa.mbn.or.jp writes:
> 
>> When a C source program uses pointer auto increment operator within a
>> loop, sometimes ivopts replaces a pointer reference to an indexed memory access,
>> which causes poor performance in my case. The detail description
>> attached bellow.  Does somebody give me a suggestion?
> 
> The usual way to address this kind of thing is to adjust the
> TARGET_RTX_COSTS hook to return appropriate costs for pointer
> addressing vs. indexed memory addressing.
> 
> If you compile with -fdump-tree-ivopts-details you will get a dump
> file which should give you some information about the costs that the
> ivopts pass is using.
> 
> Ian