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.
But I can live with any solution. So it is up to you. I am flexible.
