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.
