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]

Re: RFD: CUMULATIVE_ARGS allocation


Quoting Ian Lance Taylor <iant@google.com>:

Joern Rennecke <joern.rennecke@embecosm.com> writes:

- make INIT_CUMULATIVE_ARGS allocate using garbage-collected memory.
  That would require that each target provides appropriately
typedefed / GTY-ed
  definitions.  Multi-target operation would also require an index inside
  cumulative_args_t to decide during GC which target's GC functions to call.

As far as I can see, these issues are already issues today, as incoming_args in function.h is itself a GTY-ed structure. Note that no index inside cumulative_args_t is required; GC code can test other variables, as in the symtab field of tree_type_common in tree.h.

So I think this option is the way to go.

Option two is also GC-clean: the per-target variable can be marked as a GC root, and the other CUMULATIVE_ARGS instances would be just ephemeral entities on the stack. The unwanted link from the contents of cumulative_args_t can be avoided with GTY ((skip)).

Making GC work with an actual link from the p field to the CUMULATIVE_ARGS is
harder, because that will need to have a dispatch for GC, but a union is
impractical because of type naming issues, and too unflexible to allow
plugin backends.  So we'll need a special mechanism to dispatch to
machine-specifc GC code.  On the plus side, we can probably use the same
mechanism for struct machine_function.

Regarding the index, it would have to be *somewhere*, and it'd better match
the contents of the cumulative_args_t.  I suppose we could put it in
struct incoming_args, as the entire thing should be for one particular
function being compiled for a particular target.


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