On Wed, Sep 4, 2013 at 11:40 AM, 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?
Yes. I ran into the same problem that David just described. When
trying to unmangle all the markers, you now require gengtype to have
actual visibility into all the headers, so that the compiler can see
the actual type definitions to resolve the overloads.
> 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);
This kind of issue. Yes.
Perhaps this could be solved by not having a single header generated
for the markers. Instead, markers are generated in separate header
files that are #included by the headers that have the actual type
definitions needed for the overloads to work. Ditto for gtype-desc.c.
> 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.
That's how I think of them too. I'm not sure what the 'x' denotes.
Diego.
