AIM FOR TODAY: - Send the callstring patch to the patches list after sucessfull bootstrap and regress test - Create some basic examples to see how virtual function are being called - Layout a basic `vtable_region : public region` subclass to store vtables found till now
--- PROGRESS : - I sent the final callstring patch after sucessfully bootstraping and running the regress tests on it with no unexpected fails/passes. This time I wrote the mail manually(instead of using git send-mail) and attached the patch file with it. - while testing this on various examples I created, I found out the following : 1. vtable (which I guess looks something like _ZTV1<classname> in GIMPLE representation ) is either inside the contructor of the function or ( if default constructor is not overloaded ) in the function where the instance of the class is created. 2. when called ( call looks something like this OBJ_TYPE_REF(_3;(struct < classname>)a_7->0) (a_7); ) we get the name of the class which functions is being called and the index in vtable where address is taken. - Although at first I though it was imposible to get the info about the functions the vtable is holding by just looking at it's GIMPLE ir, after a little digging in ipa-devirt.c I found out that aprantly compiler's front end actually attaches this information ( known as BINFO ) with every tree ( RECORD_TYPE) which can be used to acess info about the same. ( I will be diggin more about it to see the extect to which I can use this BINFO to the project's advantage ) - So maybe the new region should hold a collection ( maybe vector ?) of cgraph nodes of the functions present in the vtable, which will be evaluated when the analyzer tries to find the function decl of the dynamically dicovered call. - The problem arrises when we have a base class pointer and we don't exactly know which subclasse's method is being called. In a previous discussion (https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html <https://gcc.gnu.org/pipermail/gcc/2021-April/235335.html>), a possible plan to tackle this was to "potentially have the analyzer speculate about the subclasses it knows about, adding exploded edges to speculated calls for the various subclasses." But I would like look a bit more into ipa-devirt, especially possible_polymorphic_call_targets() function ( which seems to do most of the work similar to what we want to do ) to find something to overcome this problem. --- STATUS AT THE END OF THE DAY :- - Send the callstring patch to the patches list after sucessfull bootstrap and regress test ( done ) - Create some basic examples to see how virtual function are being called ( done ) - Layout a basic `vtable_region : public region` subclass to store vtables found till now ( started ) Thank you - Ankur
