fuse-caller-save - hook format

Vladimir Makarov vmakarov@redhat.com
Thu Apr 17 16:49:00 GMT 2014


On 2014-04-17, 11:29 AM, Richard Sandiford wrote:
> 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.

Yes, you are right.  That is what I thought.  I should have read Tom's 
email with more attention.

> 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.
>

I see.  I guess your proposed solution is ok then.



More information about the Gcc-patches mailing list