Hi Everybody,
I am developing a Clang plugin in order to automate GC roots
identification on the stack in the VMKit project.
Currently, GC roots are manually identified by explicit calls to a
specific C++ function.
Then when C++ code is converted to LLVM IR, an optimization pass is
applied to replace all calls to this specific C++ function by calls to
llvm.gcroot intrinsic.
The process I am using know relies on Clang PluginASTAction and MatchFinder.
Whenever a GC root variable is matched as function parameter or local
variable, then I generate a C++ function call (with the help of Clang
Rewriter) to identify the GC root.
This works quite good in general, except for template methods.
In some cases the same method can be called with GC root parameter or
non GC root parameter (same thing for local variables / return values).
Here is a small example:
template <type T>
void foo(T obj){
// If T is of GC root type, then should
call a function to tag obj parameter.
// If T is not of GC root type, then do
nothing.
T tmp = 0; // Same issue for local variable.
/* do something here*/
}
As my solution modifies the source code, if the Matcher will match the
template parameter as GC root (and it is actually true in some cases), a
function call to identify the template parameter as GC root will be
generated in source code.
The fact that the source code is changed means that the type T should
always be a GC root type, which is actually false.
In some cases, in the previous example T can be of int type, and it will
be identified as a GC root even if it is not.
I need some help to see what I can do for solving this issue.
Does a plugin for writing template instantiation already exist in clang ?
If so, I can apply first template instantiation then launching the
matcher, avoiding the kind of problem I explained above.
Is the approach of generating source code wrong ?
Should I modify the AST directly, once template have been instantiated ?
If it is the case where can I start looking for to perform this ?
AST manipulation is not familiar to me. Some hints would be welcomed.
Thank you for your help,
--
Harris Bakiras
