On 01/17/2017 02:21 AM, Richard Biener wrote:
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?
That's what I think will currently happen. I don't know the IPA bits
very well, so I could have missed something.
But I think we can sort out these "details" when we run into them...
I can live with that -- I strongly suspect we're going to find all kinds
of things of a similar nature the more we poke at this stuff.
With that in mind, I'll go ahead and ack 9c for the trunk with the
explicit understanding that we know there's stuff that's going to break
the harder we push it and we'll incrementally work to improve it.
It certainly helps that I see this as strictly for developers, not
users. So I'm willing to be more lax on a lot of stuff.
jeff
