INIT_CUMULATIVE_ARGS (Was:Re: RFA: PR44566: accessor macros (1/3): CUMULATIVE_ARGS)

Joern Rennecke amylaar@spamcop.net
Fri Dec 17 12:26:00 GMT 2010


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.

...
> 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.  Most or all of the places that can't
use static allocation can then use alloca.
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.

DEFHOOKPOD
(cumulative_args_size,
  "The amount of memory, in bytes, that the caller should allocate when\
  passing a non-@code{NULL} @var{mem} argument to the\
  @code{init_cumulative_args} target hook.",
  size_t, sizeof (int))

DEFHOOK
(init_cumulative_args_args,
  "", /* Still waiting on the FSF to allow us to put the documentation  
here.  */
  cumulative_args_t,
  (void *mem, tree fntype, rtx libname, tree fndecl, int n_named),
  default_init_cumulative_args)



More information about the Gcc mailing list