On Sun, 2021-07-11 at 22:31 +0530, Ankur Saini wrote:
> AIM for today : 
> 
> - get "state_purge_per_ssa_name::process_point () “ to  go from the
> “return" supernode to the “call” supernode.
> - fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 <
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546> in the process 
> - test and observe the effect of changes done so far on vfunc calls
> 
> —
> 
> PROGRESS :
> 
> - In order to go from “return” supernode to “call” supernode, I used
> the fact that return supernode will have GIMPLE call statement which
> when passed to “get_supernode_for_stmt ()”  returns pointer to “call”
> supernode. 
> 
> now that part of the function look something like this 
> 
> File: {SCR_DIR}/gcc/analyzer/state-purge.cc <http://state-purge.cc/>
> 
> 347:        /* Add any intraprocedually edge for a call.  */
> 348:        if (snode->m_returning_call)
> 349:          {
> 350:                    cgraph_edge *cedge
> 351:                      = supergraph_call_edge (snode->m_fun,
> 352:                                              snode-
> >m_returning_call);
> 353:                    if(!cedge)
> 354:                    {
> 355:                            supernode* callernode = map.get_sg
> ().get_supernode_for_stmt(snode->m_returning_call);
> 356:                            gcc_assert (callernode);
> 357:                            add_to_worklist
> 358:                              (function_point::after_supernode
> (callernode),
> 359:                               worklist, logger);
> 360:                    }
> 361:                    else
> 362:                    {
> 363:                            gcc_assert (cedge);
> 364:                            superedge *sedge
> 365:                              = map.get_sg
> ().get_intraprocedural_edge_for_call (cedge);
> 366:                                    gcc_assert (sedge);
> 367:                            add_to_worklist
> 368:                              (function_point::after_supernode
> (sedge->m_src),
> 369:                               worklist, logger);
> 370:                    }
> 371:          }
> 
> - now the patch also fixes bug #100546 (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 <
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546>) and doesn’t give
> out a false report about dereferencing a null pointer which will never
> happen.
Excellent.  You should add a testcase for that bug to the test suite.

> 
> - now I tested it with vfuncs to see what happens in that case, the
> results were as expected where the analyzer detects the call to virtual
> function and split call and returning supernodes, but did not
> understand which function to calll, making nodes after it unreachable. 
> 
> - Now If we somehow able to update the regional model to understand
> which function is called ( or may be called ) then the analyzer can now
> easily call and analyze that virtual function call.

I had some ideas about how to do this here:
  https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html
which might work for simple cases where we have a code path through a
ctor of a known subclass

...but I haven't looked in detail at ipa-devirt.c yet, so I might be
wrong.

> 
> 
> STATUS AT THE END OF THE DAY :- 
> 
> - get "state_purge_per_ssa_name::process_point () “ to  go from the
> “return" supernode to the “call” supernode. ( done )
> - fix bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 <  
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546> in the process. (
> done )
> - test and observe the effect of changes done so far on vfunc calls (
> done )
> 
> —
> P.S. 
> regarding the patch I sent to mailing list yesterday. I found it,
> apparently the mail was detected as a "spam mail” by my system and was
> redirected  to my spam inbox. 

Strange.  I didn't see it in my spam folder.

> Btw I am also attaching that patch file with this mail for the records.

Thanks.  I've replied to it in another email here:
  https://gcc.gnu.org/pipermail/gcc/2021-July/236726.html

Dave

Reply via email to