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.