This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC patch: invariant addresses too cheap


Michael Matz <matz@suse.de> writes:
> Hi,
>
> On Sat, 31 Oct 2009, Richard Sandiford wrote:
>
>> Paolo Bonzini <bonzini@gnu.org> writes:
>> >> As of using a magic number there,
>> >> another option would be to have a new target macro specifying
>> >> CHEAP_ADDRESS_COST or sth like that...
>> >
>> > That would be premature.  The optimization was introduced specifically
>> > for x86, any other target probably does not care (surely not the RISC
>> > ones that always have COSTS_N_INSNS(1) for the address_cost).
>> 
>> I don't understand why it would be premature.  As Michael says, some 
>> ports don't a COSTS_N_INSNS-based value, and MIPS is one of those.  As 
>> it happens, in the MIPS costs, 1 is "cheap" and 2+ is "expensive".
>
> So that wouldn't have made a difference with the old magic number (which 
> was 4) ;-)

Right.  I'm not defending the old code either ;)

>> So either I need to hack MIPS so that 2 is cheap and 3+ is "expensive", 
>> or we need some better way of determining this.
>
> Yeah, actually that we need to determine absolute address cheapness at all 
> is a bit unsatisfying.  We probably could get away with a target 
> independend notion of when to hoist invariant addresses.  For instance, if 
> it has two register references, those registers are only used in this 
> address, then it's always a win to hoist (because it reduces register 
> pressure by one).  Then we obviously have the problem what to do with 
> offsetted addresses, some of them are cheap (small constants), some of 
> them expensive (large constant), but that's target dependend.
>
> I don't really see a good way out here, except sitting down, redefining 
> the target address cost hook (so that it's usable in its two contextes 
> it's used in now, relative cost comparisons and absolute ones), and make 
> all targets follow that.  I chickened out then :-)

How about adding a new hook to say whether it is worth considering an
address for hoisting?  A sensible default might be:

   targetm.address_cost (x, speed) > register_cost

where register_cost is the cached value of:

   targetm.address_cost (y, speed)

for an arbitrary Pmode pseudo register Y.  (I wondered about using
stack_pointer_rtx or hard_frame_pointer_rtx instead, but those registers
aren't necessarily base registers.)  We can make x86 instead use:

   targetm.address_cost (x, speed) > 2

That seems pretty clean to me, since it's the kind of thing a target
ought to control.  In future, we might even want to give the hook more
context than address_cost has (and more context than address_cost can
reasonably have in general).

It also wouldn't mean changing much.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]