This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]