Finding all CALL_EXPR tree nodes during GENERIC
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) 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. Thanks.
Re: Finding all CALL_EXPR tree nodes during GENERIC
On November 18, 2017 5:38:35 PM GMT+01:00, Katsunori Kumatani 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. Richard. > >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. > >Thanks.
Re: CFG operation leading to errors
Hi Claudiu, On Fri, Nov 17, 2017 at 03:05:23PM +, Claudiu Zissulescu wrote: > I've found a potential issue when performing CFG operations for hardware > loops. > > When a port is using hardware loops (like ARC) makes use of reorg_loops to > find and analyze loops that end in loop_end instructions. The very same > function can be set to reorder the cfg such that the loop end occurs after > the loop start. This task is performed by reoder_loops function which at its > turn calls cfg_layout_finalize -> fixup_reoreder_chain -> > force_nonfallthru_and_redirect (cfgrtl.c:1476). > However, the latter is splitting a call and its corresponding > CALL_ARG_LOCATION note, leading to an assert in dwarf2out_var_location() at > dwarf2out.c:26391. Thus, I've made a hack which patches the > force_nonfallthru_and_redirect() function to avoid splitting calls and their > note: > > diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c > index ae46908..38a739c 100644 > --- a/gcc/cfgrtl.c > +++ b/gcc/cfgrtl.c > @@ -1626,6 +1626,9 @@ force_nonfallthru_and_redirect (edge e, basic_block > target, rtx jump_label) >else > new_head = BB_END (e->src); >new_head = NEXT_INSN (new_head); > + if (new_head && NOTE_P (new_head) > + && NOTE_KIND (new_head) == NOTE_INSN_CALL_ARG_LOCATION) > + new_head = NEXT_INSN (new_head); > >jump_block = create_basic_block (new_head, NULL, e->src); >jump_block->count = count; > > I do not know if this is the way forward and I would like to have your input > on this subject. This looks correct. The same issue is handled similarly elsewhere, too. Please send the patch to gcc-patches! (Add a comment though?) Thanks, Segher
