On Thu, 2012-09-06 at 14:41 +0200, Georg-Johann Lay wrote: > 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.
As it is for other targets, too... > Can you explain how this works? > I'm not sure, however ... > 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() ... lower-subreg obviously is simply not dealding with mem loads/stores when it collects the 'SET' costs. Also notice that it calls into the target once during startup and not for each individual insn. > 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. I've noticed, that some passes (e.g. auto-inc-dec) would construct a MEM pattern and use set_src_cost instead of using address_cost. This can be handled by simply implementing the MEM case in the rtx_costs hook and re-using the target's address_cost function. In fact some targets do exactly that. > The change is definitely in the right direction, but I wonder > how it helps to fix code bloats of 300%-400% as in PR52543? I'm not familiar with the AVR parts. BTW, There was a small change in lower-subreg which required some adaptations in targets: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00425.html See also gcc/config/sh/sh.c (sh_rtx_costs): case SET: ... Not sure whether it helps in your case. > 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). Because the address cost is not considered when doing the splits. Maybe lower-subreg could be extended to pay attention to MEMs when splitting (which would complicate its costs calculations -- it probably would have to call into the target for every insn it looks at). Maybe Richard or Ian have better ideas regarding this issue. Cheers, Oleg
