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: [PATCH][ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect


Hi Richard,

On 06/05/15 08:15, Richard Sandiford wrote:
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.

Yeah, that's the mult synthesis code in expmed.c
I think the problem here with the costs infrastructure
is that the backend doesn't know for what purpose it's
assigning costs. If it's told to assign a cost to a PLUS
it has no way of knowing that the add is being considered
as part of a replacement for a mult-immediate or whether
to merge it with a shift during combine or as part of an
address calculation during ivpopts or whatever other place
in the midend that calls rtx costs.


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.

Yeah, that's a concern as well.
In any case, I'm not going to remove such increments/decrements
of costs from the backend without analysing their impact on
code quality.

Thanks,
Kyrill


Thanks,
Richard



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