This is the mail archive of the
mailing list for the GCC project.
Re: Finding all CALL_EXPR tree nodes during GENERIC
On Sun, Nov 19, 2017 at 9:27 PM, Katsunori Kumatani
> Yes, it seems walk_tree does the job, I was probably doing something
> wrong before. Thank you.
> I have a question about it. Am I correct in assuming I only have to
> check the subtrees of nodes that satisfy EXPR_P? So for nodes that
> aren't EXPR_P, can I just set *walkSubtrees to 0, or will that miss
> some CALL_EXPRs? In my tests, none were missed, but I don't know if
> this is all-encompassing for C/C++ generated AST.
You'd have to experiment, it depends on the C/C++ AST. You should be
able to skip TYPE_P though.
> Oh and another thing, is it possible to change the node (or create a
> new one and modify the source that points to it)? I assume that's why
> the first parameter to walk_tree_fn is a tree* right? That would be
> useful to know too.
Yes, you can change things.
> On Sat, Nov 18, 2017 at 6:49 PM, Richard Biener
> <email@example.com> wrote:
>> On November 18, 2017 5:38:35 PM GMT+01:00, Katsunori Kumatani <firstname.lastname@example.org> wrote:
>>>Hello, I'm doing some testing with a gcc plugin (also helped me
>>>understand a lot of how GCC works) but I've hit a roadblock.
>>>I want to find all of a function body's CALL_EXPR nodes (i.e. what
>>>calls it has) early during GENERIC, so I assume the
>>>PLUGIN_PRE_GENERICIZE hook is what I should use right?
>>>Anyway, my problem is I don't know how to find all the CALL_EXPR nodes
>>>from the DECL_SAVED_TREE of the function's decl. So what's the
>>>simplest way to do that? The routines in tree-iterator.h don't help
>>>much, they only iterate through a statement list. Do I have to go
>>>through every expr manually? Is there no API available? (walk_tree
>>>doesn't seem to handle it, or maybe I don't know how to use it)
>> Walk_tree should do it.
>>>This is obviously trivial to do in GIMPLE form (iterating through all
>>>statements and finding GIMPLE_CALL) but I need it as early as
>>>possible, so that would be in the tree representation (GENERIC?). I
>>>hope I'm just missing something obvious.