> > I don't think we should add a new target hook unless it's providing
> > genuinely new information about the target. Hooking into the RA to
> > brute-force a particular heuristic makes it harder to improve the RA
> > in future.
> >
> > There are already hooks that provide the costs of the relevant operations,
> > so I think we should concentrate on using those to get good results for
> > both Power and x86.
>
> It isn't just about Power and x86.
>
> commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
> Author: Surya Kumari Jangala <jskum...@linux.ibm.com>
> Date: Tue Jun 25 08:37:49 2024 -0500
>
> ira: Scale save/restore costs of callee save registers with block
> frequency
>
> caused regressions on many targets, including aarch64:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
>
> I don't understand why frequency can be used to scale the
> cost.
Adding such absolute hook does not seem to make sense to me, expecially
if the problem happens on multiple targets.
Let me see if I understnad what is going on. Checking one PR the patch
broke testcase:
void foo (void);
void bar (void);
int
test (int a)
{
int r;
if (r = -a)
foo ();
else
bar ();
return r;
}
Here the cost model should decide whether extra spill in
prologe/epilogue is chaper than extra spill around calls to foo() and
bar().
REG_FREQ_FROM_BB should return values in range 1....REG_FREQ_MAX which
expresses relative frequencies of BBs compressed to 0...REG_FREQ_MAX.
Avoiding 0 is to prevent cost model from thinking that spilling is
completely free.
In the case above we should have entry_block_freq = REG_FREQ_MAX (so the
epilogue/prologue cost is scaled by 1000) and frequencies of foo/bar to
have something like REG_FREQ_MAX * p and REG_FREQ_MAX * (1-p) where p is
the probability of the conditional.
So I guess IRA ends up comparing
- spill_cost * REG_FREQ_MAX for using callee saved register
- spill_cost * (p + 1-p) * REG_FREQ_MAX for using caller saved register.
Which correctly represnets that in both case we will end up executing
same amount of spill code.
If we want it to choose variant with fewer static spill count, we could
add 1 to the final costs for every spill instruction which will biass
the cost model that way...
What would make sense would be to express to IRA that moves used in
prologue/epilogue are slightly chaper on x86 then reuglar moves, since we can
use
push/pop pair which encode shorter than stack frame adjustment + regular
store/load used to spill around call.
Honza
>
> --
> H.J.
