On Wed, Sep 4, 2013 at 5:40 PM, David Malcolm <dmalc...@redhat.com> wrote:
> On Sat, 2013-08-31 at 19:27 +0200, Richard Biener wrote:
>> 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?
>
> An update: I've been trying this, but I'm running into what may be a
> blocker: types need to be visible in the declaration of the marker
> function. Doing this in gtype-desc.h runs into a tangle of dependency
> issues. For example:
>
> ./gtype-desc.h:2842:28: error: ‘ivarref_entry’ was not declared in this
> scope
> extern void gt_ggc_mx (vec<ivarref_entry,va_gc> *p);
> ^
> In the extreme case, the underlying types in question might be only
> declared in one specific .c file. In other cases, there's likely to be
> some set of header files needed to get at the types. Also, vec.h uses
> ggc.h, which uses gtype-desc.h, and so we have a loop...
>
> AIUI, the mangled names of types in the function names are doing the job
> of hiding all the types in gtype-desc.h, so that they are only needed in
> the various gt-*.h files and in gtype-desc.c. By changing things so
> that the marker function declarations refer to the types directly, all
> types need to be known to users of such functions. I'm not sure that
> that's possible - or, at least, not if the declarations are in a shared
> header file.
I think that's the issue Diego ran into. The theory with the idea was
that at the point of the struct declaration we want to generate the
marker for all those types are properly declared so their marking
prototypes would work. Which means that the marker declarations
should go alongside with struct definitions.
One idea would be to simply require explicit declarations of them
after their structs declaration.
> Perhaps it could work with some scheme in which the types are
> partitioned by .h/.c file, and copies of forward declarations are added
> only as-needed to the appropriate gt-*.h/gtype-desc.c files?
Not sure if forward declarations would work - at least autogenerated ones.
That would require gengtype parsing field types again.
Richard.
> I'm trying this now.
>
> BTW, what is the etymology of "gt_ggc_mx" and "gt_pch_nx", and how do
> people pronounce them? (I call them the "object-marking" and
> "object-noting" hooks" fwiw). As far as I can see, the "m" and and the
> "n" come from "mark" and "note"; it's not clear to me where the trailing
> "x" came from.
>
> Dave
>
