Re: progress update after initial GSoC virtual meetup

[David Malcolm <dmalcolm@redhat.com>]

On Sun, 2021-06-13 at 19:11 +0530, Ankur Saini wrote:
> 
> 
> > On 08-Jun-2021, at 11:24 PM, David Malcolm <dmalcolm@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 ?

At some point we want you to be able to push patches to trunk, so as a
step towards that I think it would be good for you to have a personal
branch on the gcc git repository.

A guide to getting access is here:
  https://gcc.gnu.org/gitwrite.html

I will sponsor you.

> 
> > 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 ?

You are correct.

What I'm thinking is that when we create the supergraph we should split
the nodes at more calls, not just at those calls that have a
cgraph_edge, but also at those that are calls to an unknown function
pointer (or maybe even split them at *all* calls).

Then, later, when engine.cc is building the exploded_graph, the
supergraph will have a superedge for those calls, and we can create an
exploded_edge representing the call.  That way if we discover the
function pointer then (rather than having it from a cgraph_edge), we
can build exploded nodes and exploded edges that are similar to the "we
had a cgraph_edge" case.  You may need to generalize some of the event-
handling code to do this.

Does that make sense?

You might want to try building some really simple examples of this, to
make it as easy as possible to see what's happening, and to debug.

> 
> >  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.

Yes.

> 
> >  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.

It sounds to me like you are on the right track.

> 
> > 
> > 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.

OK.

> 
> > 
> > > 
> > > 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

Great.

Let me know how you get on.

As I understand it, Google recommends that we're exchanging emails
about our GSoC project at least two times a week, so please do continue
to report in, whether you're making progress, or if you feel you're
stuck on something.

Hope this is constructive.
Dave