This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Describe more Sparc RTX costs
> From: Jan Hubicka <jh@suse.cz>
> Date: Sun, 5 May 2002 11:25:23 +0200
>
> > When ADDRESS_COST is constant (as it is on Alpha, Sparc, etc.)
> > CSE runs rtx_cost on the two memory expressions to break the
> > tie.
>
> Whats the purpose for doing this? Can't we just use address_cost to describe
> the difference?
>
> I have no idea, someone else more versed in how this came
> to be can tell you better than me.
>
> Maybe it is simpler to let rtx_cost implement all of the work
> since it already implements all of the machinery necessary to
> recursively walk a piece of RTL to compute it's cost.
>
> If anything, I'd argue that ADDRESS_COST should be removed because it
> is redundant and doesn't allow a target to express anything above what
> RTX_COSTS allows you to express :-)
This sounds sensible as well.
ADDRESS_COST can be implemented by RTX_COST while looking at outer code,
even when it looks a bit unnatural, maybe.
However possibly we may want to remove RTX_COST and use scheduler definition
instead, then keeping ADDRESS_COST is good idea...
Note that I believe loop optimizer still depends purely on ADDRESS_COST.
Do you have some observations how did your RTX_COST changes affected generated
code?
I am still considering whether I should do the trick for i386 too.
Honza