On 12/2/2021 2:24 PM, Iain Sandoe wrote:
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).
No worries. I was on your side of this problem eons ago, ironically in
a closely related chunk of code. I don't remember all the details
anymore. But we needed to pass around an additional argument to either
FUNCTION_ARG or INIT_CUMULATIVE_ARGS for the PA to fix an obscure issue
with passing FP values to static varargs/stdarg functions.
The concern was that re-using existing hooks would touch every target, including
all those we have no way to test.
True, but we actually do test most targets these days :-) And if we're
just adding an argument to the API for those functions, if we get it
wrong, it should be fairly obvious.
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.
Sounds good.
jeff
