Re: [PATCH 9c] callgraph: handle __RTL functions

[Jan Hubicka <hubicka at ucw dot cz>]

> On Mon, Jan 16, 2017 at 10:25 PM, Jeff Law <law@redhat.com> wrote:
> > On 01/09/2017 07:38 PM, David Malcolm wrote:
> >>
> >> The RTL backend code is full of singleton state, so we have to handle
> >> functions as soon as we parse them.  This requires various special-casing
> >> in the callgraph code.
> >>
> >> gcc/ChangeLog:
> >>         * cgraph.h (symtab_node::native_rtl_p): New decl.
> >>         * cgraphunit.c (symtab_node::native_rtl_p): New function.
> >>         (symtab_node::needed_p): Don't assert for early assembly output
> >>         for __RTL functions.
> >>         (cgraph_node::finalize_function): Set "force_output" for __RTL
> >>         functions.
> >>         (cgraph_node::analyze): Bail out early for __RTL functions.
> >>         (analyze_functions): Update assertion to support __RTL functions.
> >>         (cgraph_node::expand): Bail out early for __RTL functions.
> >>         * gimple-expr.c: Include "tree-pass.h".
> >>         (gimple_has_body_p): Return false for __RTL functions.
> >> ---
> >>  gcc/cgraph.h      |  4 ++++
> >>  gcc/cgraphunit.c  | 41 ++++++++++++++++++++++++++++++++++++++---
> >>  gcc/gimple-expr.c |  3 ++-
> >>  3 files changed, 44 insertions(+), 4 deletions(-)
> >>
> >
> >> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> >> index 81a3ae9..ed699e1 100644
> >> --- a/gcc/cgraphunit.c
> >> +++ b/gcc/cgraphunit.c
> >
> >  @@ -568,6 +591,12 @@ cgraph_node::add_new_function (tree fndecl, bool
> > lowered)
> >>
> >>  void
> >>  cgraph_node::analyze (void)
> >>  {
> >> +  if (native_rtl_p ())
> >> +    {
> >> +      analyzed = true;
> >> +      return;
> >> +    }
> >
> > So my concern here would be how this interacts with the rest of the cgraph
> > machinery.  Essentially you're saying we've built all the properties for the
> > given code.  But AFAICT that can't be true and cgraph isn't actually aware
> > of any of the properties of the native RTL code (even such things as what
> > functions the native RTL code might call).
> >
> > So I guess my question is how do you ensure that even though cgraph hasn't
> > looked at code that we're appropriately conservative with how the file is
> > processed?  Particularly if there's other code in the source file that is
> > expected to interact with the RTL native code?
> 
> I think that as we're finalizing the function from the FE before the
> cgraph is built
> (and even throw away the RTL?) we have no other choice than treating a __RTL
> function as black box which means treat it as possibly calling all function in
> the TU and reading/writing/taking the address of all decls in the TU.  Consider

I guess RTL frontend may be arranged to mark all such decls as used or just require
user to do it, like we do with asm statements.

I wonder why we need to insert those definitions into cgraph at first place...

Honza
> 
> static int i;
> static void foo () {}
> int __RTL main()
> {
>   ... call foo, access i ...
> }
> 
> which probably will right now optimize i and foo away and thus fail to link?
> 
> But I think we can sort out these "details" when we run into them...
> 
> Richard.
> 
> > Jeff