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