Oleg Endo schrieb:
On Wed, 2012-09-05 at 14:39 -0400, DJ Delorie wrote:
I don't feel the m32c change needs my specific ack, it's a harmless
change that goes with the ack for the feature itself.
However, I will note that m32c does have different costs for addresses
in different address spaces, at least when -Os.
I have created http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54496
for this.
The same is true for avr. The address costs highly depend on the
address space, no matter what -O is used.
Can you explain how this works?
For example I don't see a single call of address_cost in
lower_subreg.c what means that at least that module has
not a reasonable cost model. The costs go that odyssey:
lower-subreg.c:compute_costs()
-> rtlanal.c:insn_rtx_cost()
-> rtl.h:set_src_cost()
-> rtlanal.c:rtx_cost()
-> targetm.rtx_costs()
Each call level add some abstraction, i.e. removes information
about the insn; atually it's no more an insn, not even a pattern,
if the target hook is entered...
So at this point it appears a bit pointless to add mode
and addr_space to address_cost if the call sites don't use
that hook if it is needed.
The change is definitely in the right direction, but I wonder
how it helps to fix code bloats of 300%-400% as in PR52543?
The avr backend currently hacks around that by expanding MEM
for non-generic address space to UNSPEC. Not nice.
Describing the cost will simply have no effect (provided that
MEM -> UNSPEC hack would be reverted).
Johann
