> On 2 Dec 2021, at 21:08, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org>
> wrote:
> On 11/22/2021 8:15 AM, Richard Biener via Gcc-patches wrote:
>> On Mon, Nov 22, 2021 at 3:40 PM Maxim Blinov <maxim.bli...@embecosm.com>
>> wrote:
>>> Hi Richard,
>>>
>>> The purpose of this patch is to give more of the target code access to
>>> the cumulative_args_t structure in order to enable certain (otherwise
>>> currently impossible) stack layout constraints, specifically for
>>> parameters that are passed over the stack. For example, there are some
>>> targets (not yet in GCC trunk) which explicitly require the
>>> distinction between named and variadic parameters in order to enforce
>>> different alignment rules (when passing over the stack.) Such a
>>> constraint would be accommodated by this patch.
>>>
>>> The patch itself is very straightforward and simply adds the parameter
>>> to the two functions which we'd like to extend. The motivation of
>>> defining new target hooks was to minimize the patch size.
>> I would prefer to adjust the existing hooks if there's currently no way to
>> implement the aarch64 darwin ABI instead of optimizing for patch size.
> Agreed. Additionally I don't think we want any -f options controlling this
> behavior.
Perhaps the choice of expression was not ideal - we were trying to minimize the
invasiveness of the change (my steer to Maxim, so mea culpa there).
The concern was that re-using existing hooks would touch every target, including
all those we have no way to test.
I wonder if C++ will allow us to have a default NULL argument to the hook
so that it’s a NOP change unless a target chooses to populate that arg.
(I guess an overload will not work since we are populating a fn pointer table).
>> I have no opinion on whether passing down cummulative args is the
>> proper thing to do design-wise. It might be that
>> TARGET_FUNCTION_ARG_BOUNDARY
>> is only one part that cummulative args using code should look at
>> (given you don't show the other users of function_arg_boundary that do not
>> conveniently have a CA struct around).
> In the past I think we passed some additional parameters indicated where the
> last named parameter was so that it could be used to set up the CA struct.
> But if the aarch64 darwin ABI needs that info somewhere we didn't before,
> then we'd likely need to add the CA structure.
yeah, the problem is in knowing that we need to switch from natural alignment of
parms (so that parm N+1 is only padded sufficiently to be naturally aligned)
to word boundary.
We’ll figure out a revised patch as soon as time permits.
Iain
>
>
> Jeff
