Alan Modra <amo...@gmail.com> writes: > On Fri, Oct 30, 2020 at 09:21:09AM +0000, Richard Sandiford wrote: >> Alan Modra via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > This moves an #ifdef block of code from calls.c to >> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000, >> > define REG_PARM_STACK_SPACE or OUTGOING_REG_PARM_STACK_SPACE macros >> > that might vary depending on the called function. Macros like >> > UNITS_PER_WORD don't change over a function boundary, nor does the >> > MIPS ABI, nor does TARGET_64BIT on PA-RISC. Other targets are even >> > more trivially seen to not need the calls.c code. >> > >> > Besides cleaning up a small piece of #ifdef code, the motivation for >> > this patch is to allow tail calls on PowerPC for functions that >> > require less reg_parm_stack_space than their caller. The original >> > code in calls.c only permitted tail calls when exactly equal. >> >> Is there something PowerPC-specific that makes the relaxation safe >> for that target while not being safe on x86? > > It is quite possible that x86 can relax this condition too, I'm just > not familiar enough with all the x86 ABIs know with any certainty. By > moving the test to the target hook we allow target maintainers to have > full say in the matter. > >> I take your point about x86 and PowerPC being the only two affected >> targets. But the interface does still take an fndecl on all targets, >> so I think the target-independent assumption should be that the value >> might vary depending on function. So I guess an alternative would be >> to relax the target-independent condition and make the x86 hook enforce >> the stricter condition (if it really is needed). > > Yes, except that actually the REG_PARM_STACK_SPACE condition for > PowerPC can be removed entirely. I agree that doing as you suggest > would be OK for PowerPC, it would just mean we continue to do some > unnecessary work in the non-trivial rs6000_function_parms_need_stack.
Ah, OK. If you did the check in rs6000_function_parms_need_stack, what would the final version of the condition look like, including the future changes you have planned? My main point here is that I think it would be good to have target-independent code check the lowest common denominator that we know GCC can support on targets with nonzero REG_PARM_STACK_SPACEs, rather than force all those targets to repeat the check. (Admittedly “all” is just “two” as things stand, but still…) Targets like i386 can conservatively continue to enforce the old condition but target-independent code would follow the new and more relaxed rs6000 rules. Thanks, Richard
