Semantics of OBJ_TYPE_REF

Martin Jambor
Tue Jun 22 21:58:32 GMT 2021


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

> I am reading Hubicka's post
> on devirtualization and Part II
> (
> 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,


More information about the Gcc mailing list