Hi, On Fri, Jun 18 2021, Erick Ochoa via Gcc wrote: > Hi, > > I am having some trouble understanding the semantics of OBJ_TYPE_REF. > I understand that it is made of three operands: > > 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use. > 2. OBJ_TYPE_REF_OBJECT: Is the object on whose behalf the lookup is > being performed > 3. OBJ_TYPE_REF_TOKEN: An integer index to the virtual method table. > > The language here is very general and makes it hard for me to understand. Is > > 1. OBJ_TYPE_REF_EXPR: The virtual function
well, it is never the actual function as in a FUNCTION_DECL, it is always a pointer to an unknown function. > 2. OBJ_TYPE_REF_OBJECT: The "this" object > > ? > > Why is the index needed if it looks like the virtual function is > already pointed to by the first operand? As I wrote above, the first operand is just a pointer. Sometimes other optimizations can figure out where it leads but often not (or not early enough for inlining). In some situations we can get at the actual DECL (and subsequently have a direct call) using type based devirtualization and for that we use the other two arguments of OBJ_TYPE_REF. See the big leading comment in ipa-devirt.c. > I am reading Hubicka's post > on devirtualization and Part II > (https://hubicka.blogspot.com/2014/01/devirtualization-in-c-part-2-low-level.html) > seems to agree with me on the example below. There is also no mention > of OBJ_TYPE_REF on part II, but there is on part III. I believe the gimple quoted there has been simplified to make it easier for the reader, since it does not describe the type-based devirtualization but how other optimizations can together deduce the call target, and so OBJ_TYPE_REF has been omitted not to confuse anyone. If you dump the IL for th example yourself, you will see OBJ_TYPE_REF in the earliest dumps and you will see that it disappears as soon as the call becomes direct. Hope this helps, Martin
