This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]