RFA: PR44566: accessor macros (1/3): CUMULATIVE_ARGS

[Joern Rennecke]

Quoting Nathan Froyd <froydnj@codesourcery.com>:

> The grand plan (I was waiting until I had a patch to talk about this,
> but since you asked...), looks something like this:
>
> - Hookize FUNCTION_ARG &co.  (patch approved, I need to reassure myself
>   that some of the const-ization in the patch isn't going to break
>   bootstrap and commit)
>
> - Hookize INIT_CUMULATIVE_ARGS &co.  INIT_CUMULATIVE_ARGS is the big
>   one; I plan to convert it to something with prototype:
>
>   CUMULATIVE_ARGS *target_init_cum_args (fntype, libname, fndecl, n_named);

As has been discussed in the meantime, we need a target-independent, opaque
type for the hook interface, which can be cumulative_args_t, typedefed to a
struct or union pointer, and converted from/to the target specific type in
a pair of small inline functions.
>
>   Other hooks (INIT_CUMULATIVE_INCOMING_ARGS, for instance) will be
>   changed similarly to return a CUMULATIVE_ARGS *.  See below for
>   discussion of problem with this approach.
>
> - Convert all backends (big patch, but can be done incrementally.  I
>   have private patches for the FUNCTION_ARG &co. hookization.)
>
> - At this point, the non-backend portions of the compiler only deal with
>   CUMULATIVE_ARGS through pointers; there are no direct references.
>
>   It's possible there are other bits I am missing here, because I'm not
>   familiar with this portion of the compiler.  Repeat above steps as
>   necessary for hooks that I have failed to lookup and other bits.
>
> - In one fell swoop, s/CUMULATIVE_ARGS/struct cumulative_args/ in the
>   non-backend portions of the compiler.  Do the same in the backends,
>   moving the actual definition of 'struct cumulative_args' into the
>   backends's .c files, rather than the headers.
>
>   This is one place where C++ and virtual functions would be useful; the
>   target hooks dealing with CUMULATIVE_ARGS, I think, should really be
>   methods on a CUMULATIVE_ARGS class.  (Depending on the target, this
>   might enable removing some overhead with complicated argument passing
>   that varies with the subarchitecture.)
>
> There is one small problem with the above plan (that I am aware of;
> perhaps there are others that I am not aware of, and I would welcome
> pointers to them): what to do with managing the 'CUMULATIVE_ARGS *'
> returned by the backend?  I think the options are:
>
> - Have every backend return a pointer to statically allocated memory.
>   This is the easiest thing to do, but also likely to blow up for weird
>   uses of CUMULATIVE_ARGS.  No need to free or equivalent.  This is what
>   I was going to do.

That will be most efficient for the majority us uses, and thus should be
supported.
>
> - Allocate it in the backend hook.  Presumably we want to dictate the
>   method of allocation so we don't need to add *another* hook for
>   deallocating.  obstacks, xmalloc, whatever.  I don't have an opinion
>   here.

The problem is that that this doesn't allow you to use even alloca, so
you'd need a high-overhead allocation function.

I think it is better to have a piece-of-data target "hook" for the size
to allocate for a cumulative_args_t.
Then the init_cumulative_args hook takes a void * argument for the  allocated
memory.  Targets that are fine with the statically allocated scheme can
pass in NULL.
>
> If people think something like the above plan is the way to go, it's not
> clear to me that Joern's patch is a step forward, since
> INCOMING_ARGS_INFO will just be bitrotten after the above plan lands on
> trunk.
>
> Comments?  Criticisms?  Bets on whether this can be done before the end
> of stage 1? :)
>
> -Nathan
>