This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
INIT_CUMULATIVE_ARGS (Was:Re: RFA: PR44566: accessor macros (1/3): CUMULATIVE_ARGS)
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: Nathan Froyd <froydnj at codesourcery dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 17 Dec 2010 07:26:47 -0500
- Subject: INIT_CUMULATIVE_ARGS (Was:Re: RFA: PR44566: accessor macros (1/3): CUMULATIVE_ARGS)
- References: <20100624150200.roql5i8jkwo8sk88-nzlynne@webmail.spamcop.net> <AANLkTinw2_UwMzmlurC6TuSLEO9WYclblPKgXiir9NDI@mail.gmail.com> <20100625014234.GD12103@codesourcery.com>
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)