This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Wed, 06 May 2015 08:15:14 +0100
- Subject: Re: [PATCH][ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect
- Authentication-results: sourceware.org; auth=none
- References: <5537C9B9 dot 5090501 at arm dot com>
Kyrill Tkachov <kyrylo.tkachov@arm.com> writes:
> Hi all,
>
> This hunk that slightly reduces the cost of immediate moves doesn't
> actually have any effect. In the whole of SPEC2006 it didn't make a
> difference. In any case, I'd like to move to a point where we use
> COSTS_N_INSNS units for our costs and not increment decrement them by
> one.
I wonder whether that's always a good idea though? COSTS_N_INSNS exists
to allow these kinds of fractional costs. It sounds like they're
not useful in this particular case, but e.g. one case where they
can be useful is if you want to say when optimising for size that two
instructions are the same size but one is slightly more preferable for
speed reasons. This might help prefer a 2-instruction shift/add
sequence over a load-immediate followed by a general multiplication;
both have the same size, but the shift/add is often faster. Giving
multiplication a slightly higher cost than COSTS_N_INSNS (1) makes
that clear.
It's not perfect of course. Add too many fractional costs together
and a carry will give you an extra full instruction at some fairly
arbitrary point. Maybe size costs should be a (size, speed) pair.
Thanks,
Richard