whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

[Leslie Zhai]

Hi David,

Thanks for your kind response!


在 2017年07月11日 21:25, David Malcolm 写道:
> On Tue, 2017-07-11 at 10:50 +0800, Leslie Zhai wrote:
>> 在 2017年07月10日 22:16, David Malcolm 写道:
>>> On Sat, 2017-07-08 at 15:50 +0800, Leslie Zhai wrote:
>>>> Hi GCC developers,
>>>>
>>>> There was
>>>>
>>>> PLUGIN_REGISTER_GGC_CACHES
>>>>
>>>> pseudo-events for register_callback in GCC v4.x, but how to
>>>> migrate
>>>> it
>>>> for GCC v6.x? there is no  PLUGIN_REGISTER_GGC_CACHES deprecated
>>>> log
>>>> in
>>>> ChangeLog-201X nor git log plugin.h... please give me some hint,
>>>> thanks
>>>> a lot!
>>> Trevor [CCed] removed it 2014-12-10 in r218558
>>> (eb06b2519a361b7784b1807115fcb3dea0226035) in the commit:
>>> "remove gengtype support for param_is use_param, if_marked and
>>> splay
>>> tree allocators"
>>>
>>> The patch was here:
>>>     https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02965.html
>>>
>>> where he talks about plugin migration.
>>    Some plugins may need to add extra GGC root tables, e.g. to handle
>> their own
>>    @code{GTY}-ed data. This can be done with the
>> @code{PLUGIN_REGISTER_GGC_ROOTS}
>>    pseudo-event with a null callback and the extra root table (of type
>> @code{struct
>> -ggc_root_tab*}) as @code{user_data}.  Plugins that want to use the
>> -@code{if_marked} hash table option can add the extra GGC cache
>> tables
>> generated
>> -by @code{gengtype} using the @code{PLUGIN_REGISTER_GGC_CACHES}
>> pseudo-event with
>> -a null callback and the extra cache table (of type @code{struct
>> ggc_cache_tab*})
>> -as @code{user_data}.  Running the @code{gengtype -p @var{source-dir}
>> -@var{file-list} @var{plugin*.c} ...} utility generates these extra
>> root
>> tables.
>> +ggc_root_tab*}) as @code{user_data}.  Running the
>> + @code{gengtype -p @var{source-dir} @var{file-list} @var{plugin*.c}
>> ...}
>> +utility generates these extra root tables.
>>
>>
>> After diff gcc-6.3.0/gcc/testsuite/gcc.dg/plugin and
>> gcc-4.8.0/gcc/testsuite/gcc.dg/plugin
>> then migrate to GCC v6.x like this:
>>
>>
>> // Register our garbage collector roots.
>> #if GCC_MAJOR < 6
>>     register_callback(plugin_name, PLUGIN_REGISTER_GGC_CACHES, NULL,
>> #else
>>     register_callback(plugin_name, PLUGIN_REGISTER_GGC_ROOTS, NULL,
>> #endif
>>                       const_cast<ggc_cache_tab
>> *>(gt_ggc_rc__gt_cache_h));
>>
>>
>> and Trevor talks more about GTY((if_marked(XXX), param_is(XXX)))
>> htab_t
>> migrate to GTY((cache)) hash_table<MyHasher> such as:
>>
>>
>> #if (GCC_MAJOR < 6)
>> // FIXME: gengtype not support macro?
>> static GTY((if_marked("tree2int_marked_p"), param_is(struct
>> tree2int)))
>>       htab_t intCache;
>> #else
>> struct intCacheHasher : ggc_cache_ptr_hash<tree2int> {
>>     static inline hashval_t hash(tree2int *t2i) {
>>       return tree_map_base_hash(&t2i->base);
>> }
>>
>>     static inline bool equal(tree2int *a, tree2int *b) {
>>       return a->base.from == b->base.from;
>> }
>> };
>> static GTY((cache))
>>       hash_table<intCacheHasher> *intCache;
>> #endif
>>
>>
>> But I have no idea why gengtype does not support macro?
>> https://gcc.gnu.org/ml/gcc/2017-07/msg00045.html it just ignored #if
>> (GCC_MAJOR < 6) still parse GTY((if_marked(XXX), param_is(XXX)))
>> htab_t
>> but not GTY((cache)) hash_table<MyHasher>... please give me some
>> hint,
>> thanks a lot!
> Unfortunately, gengtype is not a full parser for all of C++; IIRC it
> doesn't have any real support for the preprocessor.
>
> Maybe you can work around it in your plugin by providing two different
> headers, one for GCC_MAJOR < 6, the other for >= 6, and setting up the
> build so that gengtype is invoked on the correct header.  (I know this
> is ugly, sorry).
>
> Alternatively, maybe there's another way to solve this by rethinking
> the data structure.  It seems like you have a hash table of some kind.
>   Does the hash table "own" references to other GC-managed entities, or
> is it simply referenced *by* other GC-managed entities.  Maybe there's
I am migrating dragonegg to GCC v6.3 and LLVM v3.9, at first it needs to 
be built successfully, no warning is better :) but I only migrated part 
of it, for example: Caching values in GCC trees right now 
https://github.com/xiangzhai/dragonegg/blob/gcc-6_3-branch/src/Cache.cpp 
and the relationship might be: GTY((cache)) hash_table<intCacheHasher> 
*intCache <- Cache::setCachedInteger <- TypeConversion::set_decl_index...
When I finished the migration, with the whole view, then I need to 
rethink the data structure as you suggested.

PS: Trevor's email is not available? thanks!


> another way to represent this data which would sidestep the issue.  (I
> don't know, I'm just speculating).
>
> Hope this is helpful
> Dave

-- 
Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/