RFC: semi-automatic hookization
Joern Rennecke
amylaar@spamcop.net
Tue Nov 16 17:34:00 GMT 2010
Quoting Ian Lance Taylor <iant@google.com>:
> Joern Rennecke <amylaar@spamcop.net> writes:
>
>> Before I go and make all these target changes & test them, is there at
>> least agreemwent that this is the right approach, i.e replacing
>> CUMULATIVE_ARG *
>> with void *, and splitting up x_rtl into two variables.
>
> I don't know how we want to get there, but it seems to me that the place
> we want to end up is with the target hooks defined to take an argument
> of type struct cumulative_args * (or a better name if we can think of
> one). We could consider moving the struct definition into CPU.c, and
> having the target structure just report the size, or perhaps a combined
> allocation/INIT_CUMULATIVE_ARGS function.
If every target defines struct cumulative_args, allocation is straightforward.
ctmrtl (or if you think a better name, propose one) is a macro for the
global variable x_tm_rtl, which is defined in target-oriented middle-end
code that includes tm.h .
What is not quite clear is what is to happen with the args member of x_rtl.
Should I remove the info member from struct incoming_args, and shift that
to x_tm_rtl, or should I rather move the entire args member of x_rtl to
x_tm_rtl? The latter would mean that struct incoming_args would remain
intact - but OTOH more churn in config/*/*, because every access to crtl->args
will have to be changed.
Or maybe we should leave the target-specific stuff in x_rtl / crtl and
instead move out the stuff that emit-rtl.h makes visible to non-rtl code,
e.g. x_first_insn, x_last_insn ...
More information about the Gcc
mailing list