This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: i386 constant costs tweek
- To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org, patches at x86-64 dot org, kenner at vlsi1 dot ultra dot nyu dot edu
- Subject: Re: i386 constant costs tweek
- From: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 5 Jun 2001 16:10:10 +0200
- References: <20010604192123.I25024@atrey.karlin.mff.cuni.cz> <20010604134620.H24844@redhat.com>
> On Mon, Jun 04, 2001 at 07:21:23PM +0200, Jan Hubicka wrote:
> > It seems to make sense for me to define the costs negaitve,
>
> I don't think you can do this. All you can do is return 0.
I was worried about, but it seems to me that most code just
compares costs relativly, so using negative values is the
same as giving nonzero cost to register (that may make more sense).
Defining constant to 0 can be OK for my purposes too, but we
will lose ability to prioritize over constants with different
costs (-127..128 versus general).
On the other hand, I don't see any direct gain from doing so.
We can't simply replace once constant by another, so all
it can is to choose between various complex expressions,
but only one should be canonical, so this case should not
happen much.
So do you think setting all the costs for constant to 0 is OK?
(or alternatively current approach with negative costs, or
giving cost to register and updating all CONST_COST?
Honza
>
>
> r~