David Malcolm <dmalc...@redhat.com> wrote:
>On Fri, 2013-08-30 at 10:09 +0200, Richard Biener wrote:
>> On Thu, Aug 29, 2013 at 9:44 PM, Steven Bosscher
><stevenb....@gmail.com> wrote:
>> > On Thu, Aug 29, 2013 at 6:20 PM, David Malcolm
><dmalc...@redhat.com> wrote:
>> >> * gimple.c (gt_ggc_mx (gimple)): New, as required by
>GTY((user)).
>> >> (gt_pch_nx (gimple)): Likewise.
>> >
>> > GIMPLE isn't supposed to end up in a PCH. Can you please make this
>> > function simply call gcc_unreachable()?
>> >
>> > FWIW 1: I really think all these hand-written markers aren't a good
>> > idea, we should really figure out a way to have automatic marker
>> > function generators, something less complex than gengtype, of
>course.
>> > But to have all these calls to the type-mangled marker functions
>> > (gt_pch_n_9tree_node, etc.) is going to be a problem in the long
>term.
>> >
>> > It seems to me that the first step in all these conversions to
>> > hand-written markers should be to make gengtype spit out the marker
>> > functions *without* the type name mangling, i.e. all marker
>functions
>> > should just be gt_ggc_mx(type) / gt_pch_nx(type).
>>
>> Yes, the original idea was that gengtype would do that. For things
>we like
>> to optimize the GTY((user)) thing would tell it that we do provide
>the markers.
>> Like when you want to look through a non-GCed intermediate object.
>Or
>> for things like GTY((chain)) stuff that doesn't really work if you
>have multiple
>> chains (without clever GTY((skip))s...).
>>
>> The lack of the unmangled overloads is annoying :/ IIRC Diego
>halfway completed
>> the transition to unmangled overloads / specializations?
>
>How would that work, and is that something that it would be productive
>for me to work on?
>
>Currently AIUI gtype-desc.h contains mangled macros and decls e.g.:
> extern void gt_ggc_mx_rtvec_def (void *);
> #define gt_ggc_m_9rtvec_def(X) do { \
> if (X != NULL) gt_ggc_mx_rtvec_def (X);\
> } while (0)
>
>and the corresponding functions in gtype-desc.c contain:
>
>void
>gt_ggc_mx_rtvec_def (void *x_p)
>{
> struct rtvec_def * const x = (struct rtvec_def *)x_p;
> if (ggc_test_and_set_mark (x))
> {
> /* visit fields of x, invoking the macros */
> }
>}
>
>Is the goal for the field-visiting code to all be able to simply do:
> gt_ggc_mx (field)
Yes. The advantage is that gengtype this way only needs to parse field names
and not types which is a lot easier.
>and have overloading resolve it all? (and handle e.g. chain_next etc
>etc)
Yes. All bits that would require more complex parsing should instead be telled
explicit via a GTY annotation.
>Presumably if this were implemented, then hand-written GTY functions
>would be that much easier to maintain, and perhaps this gimple
>conversion idea would be more acceptable? (or, in other words, should
>I
>work on this?)
That would be very nice! IIRC Diego had issues with making all declarations
visible to make this work. Diego?
Richard.
>Thanks
>Dave
