GCC 8: adding, thru a plugin, an analyzing RTL pass after pro_and_epilogue issue with its reference_pass_name

[David Malcolm]

On Wed, 2019-04-10 at 17:53 +0200, Basile Starynkevitch wrote:
> Hello All,
> 
> This is work done for the CHARIOT H2020 project (see 
> https://www.chariotproject.eu/ for more context) in relation with my 
> BISMON project (see http://github.com/bstarynk/bismon/ for more, and,
> if 
> you want more context, read the draft report on 
> http://starynkevitch.net/Basile/bismon-chariot-doc.pdf but skip the
> few 
> first pages for H2020 managers).
> 
> I have to make a preliminary proof-of-concept that my BISMON project 
> could be useful, with some ad-hoc GCC 8.3 plugin, to compute a crude 
> approximation of the call stack of a tiny freestanding kernel (for
> x86 
> in 32 bits, so compiled with: gcc-8 -ffreestanding -m32 -O2 -Wall 
> -fstack-usage and my plugin).
> 
> I am working right now on that hand-written GCC 8.3 plugin. It
> inserts 
> two GCC passes, and both passes are only analyzing passes (they
> don't 
> change a single bit of GIMPLE or RTL representations).
> 
> The first pass, named chariot_callgraph, is (oversimplifying)
> printing 
> the call graph (and I will improve later that pass to communicate
> with 
> BISMON).  It is a pass of kind GIMPLE_PASS successfully inserted
> after 
> the reference_pass_name "sra" and it works well enough.
> 
> The second pass, named chariot_framesize, is (oversimplifying)
> expected 
> to run with the printing the call frame size (and I will improve
> later 
> that pass to communicate with BISMON).
> 
> I want to insert that second pass following this explanation (in a 
> comment of mine).
> 
>    /* the fun->su exists as soon as -fstack-usage is passed, but it
> is
>       filled much later, by the RTL pass named "pro_and_epilogue" at
>       gcc-8.3.0/gcc/config/i386/i386.c:13930 in function
>       ix86_expand_prologue; that pass is
>       pass_data_thread_prologue_and_epilogue defined in
> gcc/function.c
>       line 6553 ... */
> 
> 
> To insert that second pass, I tried many things and failed. I was 
> expecting that an rtl- prefix is needed for an RTL pass. My
> plugin_init 
> contains
> 
> 
>    struct register_pass_info my_framesize_pass_info;
>    my_framesize_pass_info.pass = make_pass_chariot_framesize (g);
>    //#warning the below reference pass name is wrong for 
> my_framesize_pass_info
>    my_framesize_pass_info.reference_pass_name = "rtl-
> pro_and_epilogue";
>    my_framesize_pass_info.ref_pass_instance_number = 1;
>    my_framesize_pass_info.pos_op = PASS_POS_INSERT_AFTER;
>    register_callback (plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL,
>                       &my_framesize_pass_info);
> 
> But for some reason I cannot understand the reference_pass_name is 
> wrong. Using "rtl-pro_and_epilogue" don't work. And I tried many 
> variants without any success during several hours.
> 
> 
> So what is the reference_pass_name to use with register_callback
> like 
> above to mention that pass_data_thread_prologue_and_epilogue defined
> in 
> gcc/function.c line 6553 ?

It's been a long time since I touched this code, but the gcc-python-
plugin has an example of an RTL pass in a plugin (albeit in Python)
https://github.com/davidmalcolm/gcc-python-plugin/blob/master/tests/plugin/new-passes/script.py#L97

I just smoketested it and the pass appears to get run.

Specifically, my example registers the plugin pass after "expand" (so I
don't think you need the "rtl-" prefix there; I think these prefixes
are for dump names rather than pass names).

Hope this is helpful
Dave



> 
> The entire code (of that proof-of-concept work in progress) is 
> temporarily available on 
> http://starynkevitch.net/Basile/chariotdemo-2019-Apr-10-5414f7e3a173.
> tar.bz2 
> which is a small archive of 14340 bytes. Please notice that the code
> I 
> have written in collaboration with my colleagues Franck Védrine (in
> BCC) 
> and Yves Lhuillier at CEA LIST is under GPLv3+ license. But that
> example 
> also contains some third-party tiny code taken from 
> https://wiki.osdev.org/Bare_Bones and in good faith we don't know
> what 
> license is that code (files kernel.c etc...) but we guess it is
> morally 
> in the public domain or open source (but we are not lawyers) since
> given 
> as an example on some wiki page.
> 
> Regards
> 
>