> On 08-Jun-2021, at 11:24 PM, David Malcolm <dmalc...@redhat.com> wrote:
>
> Is there a URL for your branch?
no, currently it only local branch on my machine. Should I upload it on a
hosting site ( like GitHub ) ? or can I create a branch on remote also ?
> The issue is that the analyzer currently divides calls into
> (a) calls where GCC's middle-end "knows" which function is called, and
> thus the call site has a cgraph_node.
> (b) calls where GCC's middle-end doesn't "know" which function is
> called.
>
> The analyzer handles
> (a) by building call and return edges in the supergraph, and
> processing them, and
> (b) with an "unknown call" handler, which conservatively sets lots of
> state to "unknown" to handle the effects of an arbitrary call, and
> where the call doesn't get its own exploded_edge.
>
> In this bug we have a variant of (b), let's call it (c): GCC's middle-
> end doesn't know which function is called, but the analyzer's
> region_model *does* know at a particular exploded_node.
but how will the we know this at the time of creation of supergraph? isn’t
exploded graph and regional model created after the supergraph ?
> I expect this kind of thing will also arise for virtual function calls.
yes, it would be a similar case as if the call is not devirtualised, GCC’s
middle-end would not know which function is being called but our regional model
would know about the same.
> So I think you should look at supergraph.cc at where it handles calls; I
> think we
> need to update how it handles (b), so that it can handle the (c) cases,
> probably by splitting supernodes at all call sites, rather than just
> those with cgraph_edges, and then creating exploded_edges (with custom
> edge info) for calls where the analyzer "figured out" what the function
> pointer was in the region_model, even if there wasn't a cgraph_node.
>
> Does that make sense?
ok so we are leaving the decision of how to handle case (b) to explodedgraph
with the additional info from the regional model and create a call and return
supernodes for all type of function calls whether or not middle-end know which
function is called or not, makes sense. ( ok so this answers my previous
question )
I went through supergraph.cc <http://supergraph.cc/> and can see the splitting
happening in the constructor’s (supergraph::supergraph() ) at the end of first
pass.
>
> Or you could attack the problem from the other direction, by looking at
> what GCC generates for a vfunc call, and seeing if you can get the
> region_model to "figure out" what the function pointer is at a
> particular exploded_node.
I will also be looking at this after the fixing the above problem, my current
plan is to see how GCC's devirtualiser do it.
>
>>
>> also, should I prefer discussing about this bug here( gcc mailing
>> list) or on the bugzilla itself ?
>
> Either way works for me. Maybe on this list? (given that this feels
> like a design question)
ok
>
> Hope this is helpful
> Dave
Thanks
- Ankur
