Tom de Vries <tom_devr...@mentor.com> writes:
> Vladimir,
>
> All patches for the fuse-caller-save optimization have been ok-ed. The only
> part
> not approved is the MIPS-specific part.
>
> The objection of Richard S. is not so much the patch itself, but more the idea
> of the hook fn_other_hard_reg_usage.
>
> For clarity, I'm restating the current hook definition here:
> ...
> +@deftypefn {Target Hook} bool TARGET_FN_OTHER_HARD_REG_USAGE (struct
> hard_reg_set_container *@var{regs})
> Add any hard registers to @var{regs} that are set or clobbered by a call to
> the
> function. This hook only needs to add registers that cannot be found by
> examination of the final RTL representation of a function. This hook returns
> true if it managed to determine which registers need to be added. The default
> version of this hook returns false.
> ...
Just for the record, I think this hook was defined as applying during final
to a potential callee function, rather than applying to a particular call.
I.e., after calculating which registers a function uses, the code would
add the registers returned by this hook to the set.
My objection to that was that the set of registers clobbered while making
a call depends on the caller.
With that proviso...
> Richard prefers to, rather than having a hook specifying what registers are
> implicitly clobbered, adding those clobbers to CALL_INSN_FUNCTION_USAGE.
...I agree this is a fair summary.
> I can see these possibilities (and perhaps there are more):
>
> 1. We go with Richards proposal: we make each target responsible for adding
> these clobbers in CALL_INSN_FUNCTION_USAGE, and use a hook called f.i.
> targetm.fuse_caller_save_p or targetm.implicit_call_clobbers_in_fusage_p, to
> indicate whether a target has taken care of that, meaning it's safe to do the
> fuse-caller-save optimization.
>
> 2. A mixed solution: we make each target responsible for specifying which
> clobbers need to be added in CALL_INSN_FUNCTION_USAGE, using a hook called
> f.i.
> targetm.call_clobbered_regs, and add generic code to add those clobbers to
> CALL_INSN_FUNCTION_USAGE.
>
> 3. We stick with the current, approved hook format, and try to convince
> Richard
> to live with it.
The reason I don't like (2) is that, on targets like MIPS where the
different call cases are quite complicated, the implementation of
the hook would need to follow the same logic as the call expander
to figure out which case applies. It just seems more elegant to me
to add the clobbers when emitting the call.
IMO CALL_INSN_FUNCTION_USAGE is like a "varargs" part of the call pattern.
In other words it's a way of allowing the set of uses and clobbers to
vary from call to call without having to define lots of different call
define_insns. If you look at it like that, adding the clobbers when
emitting the insn seems more correct as well.
Thanks,
Richard
