Re: fuse-caller-save - hook format

[Richard Sandiford <rdsandiford at googlemail dot com>]

Vladimir Makarov <vmakarov@redhat.com> writes:
> On 2014-04-16, 3:19 PM, Tom de Vries wrote:
>> 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.
>> ...
>> 
>> Richard prefers to, rather than having a hook specifying what registers are
>> implicitly clobbered, adding those clobbers to CALL_INSN_FUNCTION_USAGE.
>> 
>> 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.
>> 
>> 
>> Since you are a register allocator maintainer, familiar with the
>> fuse-caller-save optimization, and have approved the original hook, I
>> would like
>> to ask you to make a decision on how to proceed from here.
>> 
>
> I have no preferences and it is a matter of taste.  Each solution has
> own advantages and disadvantages.  Putting this info into
> CALL_INSN_FUNCTION_USAGE helps GCC developing a lot but it has a big
> drawback in RTL memory footprint (especially for some targets which have
> a lot of regs like AM29k or IA64).  On the order hand analogous approach
> is already used in DF-infrastructure (which would be nice to fix it imho).
>
> Still between GCC users and GCC developers, I'd prefer solution (even
> the effect on amount of resources used by GCC is quite insignificant)
> for users as their number is in a few magnitudes more then the developers.

Hmm, but you're talking like there are going to be a lot of these registers.
This isn't about which registers are call-clobbered or call-saved according
to the ABI (that's already available in other places).  All we want here
are the set of registers that are clobbered _in the caller_ before reaching
the callee or after the callee has returned.

So although IA-64 has lots of registers, the caller doesn't AFAIK use
lots of registers in the process of making the call.

On all targets we should be talking about one or two registers here.

Thanks,
Richard