| Message ID | 5537C9B9.5090501@arm.com |
|---|---|
| State | New |
| Headers | show |
Ping. https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01330.html Thanks, Kyrill On 22/04/15 17:18, Kyrill Tkachov wrote: > 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. > > This patch removes that bit of logic and makes it slightly cleaner to look at. As far as I know > its logic has never been confirmed in practice. > > Bootstrapped and tested on arm. > > Ok for trunk? > > Thanks, > Kyrill > > 2015-04-22 Kyrylo Tkachov <kyrylo.tkachov@arm.com> > > * config/arm/arm.c (arm_new_rtx_costs): Do not lower cost > immediate moves.
On 22 April 2015 at 17:18, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: > 2015-04-22 Kyrylo Tkachov <kyrylo.tkachov@arm.com> > > * config/arm/arm.c (arm_new_rtx_costs): Do not lower cost > immediate moves. OK /Marcus
On 30 April 2015 at 16:22, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > On 22 April 2015 at 17:18, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: > >> 2015-04-22 Kyrylo Tkachov <kyrylo.tkachov@arm.com> >> >> * config/arm/arm.c (arm_new_rtx_costs): Do not lower cost >> immediate moves. > > OK > /Marcus Ignore that, I'm not allowed to make that call. Wait for Ramana. /Marcus
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
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 >
commit e225669ff70f09520007b7898b170fb8fa75281f
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date: Wed Apr 8 10:18:23 2015 +0100
[ARM] Do not lower cost of setting core reg to constant. It doesn't have any effect
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0ef05c9..03988ac 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -9725,11 +9725,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
and we would otherwise be unable to work out the true cost. */
*cost = rtx_cost (SET_DEST (x), SET, 0, speed_p);
outer_code = SET;
- /* Slightly lower the cost of setting a core reg to a constant.
- This helps break up chains and allows for better scheduling. */
- if (REG_P (SET_DEST (x))
- && REGNO (SET_DEST (x)) <= LR_REGNUM)
- *cost -= 1;
+
x = SET_SRC (x);
/* Immediate moves with an immediate in the range [0, 255] can be
encoded in 16 bits in Thumb mode. */
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. This patch removes that bit of logic and makes it slightly cleaner to look at. As far as I know its logic has never been confirmed in practice. Bootstrapped and tested on arm. Ok for trunk? Thanks, Kyrill 2015-04-22 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * config/arm/arm.c (arm_new_rtx_costs): Do not lower cost immediate moves.