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

Joern Rennecke <joern.renne...@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.

Reply via email to