On Mon, Jan 16, 2017 at 10:25 PM, Jeff Law <[email protected]> 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
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
