[CIR] Add special type and new operations for vptrs #1745

andykaylor · 2025-07-15T20:35:58Z

This change introduces a new type, cir.vptr, and two new operations, cir.vtable.get_vptr and cir.vtable.get_virtual_fn_addr to make operations involving vptrs more explicit. This also replaces cases where cir.vtable.address_point was being used as a general GEP-like operation and not actually returning the address point of a vtable.

xlauko

General comments – potentially worth clarifying in documentation, naming, or as future improvements:

Is this type intended only for top-level vtable manipulation, i.e., not for representing specific vtable elements? It's currently unclear whether pointer arithmetic is meant to be allowed here.

If the intention is to also represent individual vtable elements (e.g., a pointer to a function pointer), a name like !cir.vtable_element (or similar) might be more descriptive. As it stands, !cir.ptr<!cir.vtable> suggests that another level of indirection or some additional operation is required to access the actual function pointer.

On the other hand, I dislike use of !cir.vtable_element in cases like dynamic_cast, where a different abstraction may be more appropriate.

Perhaps it would make sense to introduce two distinct types:
- !cir.vtable_ptr (instead of !cir.ptr<!cir.vtable>) to disallow arbitrary pointer arithmetic on vtables.
- A separate type to represent specific vtable elements.

I’m basing this feedback primarily on what’s visible in this PR—I haven’t done a deep dive into where and how vtables are intended to be used across the broader system. Nonetheless, these use cases might be worth clarifying in the type documentation.

It might be worth considering the addition of dedicated vtable-related operations in the future, to avoid relying on long chains of casts, loads, and stores?
How does this representation relate to cir::MethodType? Some clarification around this would be helpful, especially in terms of how method types are expected to interact with vtables. But this is probably for further discussion as method types feels half baked.

Also, I’ve been reviewing how other high-level IRs handle similar concepts. One worth examining is Swift SIL.

xlauko · 2025-07-16T05:19:20Z

clang/include/clang/CIR/Dialect/IR/CIRTypeConstraints.td

+def CIR_AnyVTableType : CIR_TypeBase<"::cir::VTableType",
+    "vtable type">;
+


Suggested change

def CIR_AnyVTableType : CIR_TypeBase<"::cir::VTableType",

"vtable type">;

def CIR_AnyVTableType : CIR_TypeBase<"::cir::VTableType", "vtable type">;

xlauko · 2025-07-16T05:19:55Z

clang/include/clang/CIR/Dialect/IR/CIRTypes.td

+def CIR_VTableType : CIR_Type<"VTable", "vtable",
+    [DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {
+


Suggested change

def CIR_VTableType : CIR_Type<"VTable", "vtable",

[DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {

def CIR_VTableType : CIR_Type<"VTable", "vtable", [

DeclareTypeInterfaceMethods<DataLayoutTypeInterface>

]> {

andykaylor · 2025-07-16T23:01:42Z

@xlauko Thanks for the review! It does seem as though I've greatly oversimplified this. I'm going to put it aside for now, because it does need some more thought. I'll definitely add more documentation when I get back to it.

andykaylor · 2025-07-30T17:55:53Z

@tommymcm I couldn't add you as a reviewer, but I'd like to hear your thoughts on this change.

tommymcm · 2025-07-30T19:36:18Z

Thanks for the ping. Overall, I like the design. Here's some questions/notes.

Does a cir.vptr point to the start of the virtual functions, or the top of the vtable contents? Similarly, where does a cir.ptr<cir.vtable> point to? Is there a difference between the two?

Clarifying question about offsets: If I have the class definitions:

class Base { virtual int foo(); virtual int bar(); };
class Derived : Base { int foo() override; int bar() override; };

Do I get a pointer to Derived::bar() with cir.vtable.get_virtual_fn_addr(%vptr, index = 1)? Or am I indexing from somewhere else in the vtable?

Question: Does this work with multiple inheritance? For example:

class Duck { virtual ~Duck(); virtual int quack(); };
class Dog { virtual ~Dog(); virtual int woof(); };
class DuckDog : Duck, Dog { int quack() override; }

How do I get the vptr for Dog from a DuckDog? Do I need to gep into the Dog sub-object first?

Similar question: Does this work out of the box for virtual inheritance? Or will things need to change to support that?

andykaylor · 2025-07-30T20:53:56Z

Thanks for the ping. Overall, I like the design. Here's some questions/notes.

Does a cir.vptr point to the start of the virtual functions, or the top of the vtable contents? Similarly, where does a cir.ptr<cir.vtable> point to? Is there a difference between the two?

That depends on what is returned by cir.vtable.address_point (or cir.vtt.address_point in the case of classes with virtual bases) which in turn depends on the ABI (though the current implementation of cir.vtable.address_point seems to encode a bit of ABI information). For the Itanium ABI and the relative offset ABI, the vptr points to the start of the virtual function table (unless a VTT is required).

I've eliminated the cir.vtable type that I had introduced in the first draft of this PR. It could be worth introducing new types for VTables and VTTs, but I'm not attempting that here.

Also, I should mention that this PR doesn't change the physical layout of these objects at all. I'm just changing the abstractions used to access the objects.

Clarifying question about offsets: If I have the class definitions:
class Base { virtual int foo(); virtual int bar(); };
class Derived : Base { int foo() override; int bar() override; };
Do I get a pointer to Derived::bar() with cir.vtable.get_virtual_fn_addr(%vptr, index = 1)? Or am I indexing from somewhere else in the vtable?

cir.vtable.get_virtual_fn_addr(%vptr, index = 1) will index into the virtual function table provided by the %vptr operand, so it may point to Derived::bar() or Base::bar(). It depends on the dynamic type of the object that was used to get the vptr.

Possible dragon: Does this work with multiple inheritance? For example:
class Duck { virtual ~Duck(); virtual int quack(); };
class Dog { virtual ~Dog(); virtual int woof(); };
class DuckDog : Duck, Dog { int quack() override; }
How do I get the vptr for Dog from a DuckDog? Do I need to gep into the Dog sub-object first?

Good question. You would use cir.base_class_addr to get a pointer to the Dog base within DuckDog and then use cir.get_vptr to get the Dog vptr.

Similar question: Does this work out of the box for virtual inheritance? Or will things need to change to support that?

Virtual inheritance requires the use of VTTs, which are implemented, but may benefit from a similar change in abstractions. I haven't dug into that much yet.

tommymcm · 2025-07-30T21:41:45Z

Wicked, thanks for the answers and sorry for some of them being a bit vague. I think this is a good change and fixes a lot of the headaches I have had when debugging C++ support in CIRGen. It might be good to add some C++ examples in the op descriptions to document what you described above.

Lancern · 2025-07-31T16:34:45Z

clang/test/CIR/CodeGen/dynamic-cast.cpp

+// AFTER-NEXT:     %[[#ELEM_PTR:]] = cir.cast(bitcast, %[[#VPTR]] : !cir.vptr), !cir.ptr<!s64i>
+// AFTER-NEXT:     %[[#MINUS_TWO:]] = cir.const #cir.int<-2> : !s64i
+// AFTER-NEXT:     %[[#BASE_OFFSET_PTR:]] = cir.ptr_stride(%[[#ELEM_PTR]] : !cir.ptr<!s64i>, %[[#MINUS_TWO:]] : !s64i), !cir.ptr<!s64i>


This sequence of operations effectively get the vtable element at address point -2 which records the base-to-complete offset. I believe we will have a dedicated op for this operation (and also for other special address points such as the RTTI ptr) later so we don't have to bit-cast beween !cir.vptr and !cir.ptr<...>, right?

Yes, that is my intent. The old sequence here did the same thing, but it was overloading the cir.vtable.address_point operation in a way that was rejected by the verifier when I added the constraint that cir.vtable.address_point should return a pointer to cir.vptr. I plan to add an operations in a future change that explicitly retrieves a pointer to the base-to-complete offset entry. I'm thinking something like cir.vtable.get_complete_offset_addr which will take a vptr as an input and return a pointer to integer.

xlauko

overall this seems reasonable, I just have few technical and style comments

xlauko · 2025-07-31T19:40:00Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

@@ -2624,6 +2625,101 @@ def CIR_VTableAddrPointOp : CIR_Op<"vtable.address_point",[
  let hasVerifier = 1;
 }

+//===----------------------------------------------------------------------===//
+// VTableGetVptr


nit: to be consistent with type name this should be VTableGetVPtr

xlauko · 2025-07-31T19:40:47Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+  let arguments = (ins
+                   Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);
+


Suggested change

let arguments = (ins

Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);

let arguments = (ins

Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src

);

xlauko · 2025-07-31T19:41:10Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+                   Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);
+
+  let results = (outs CIR_PtrToVPtr:$vptr_ty);
+


Suggested change

xlauko · 2025-07-31T19:43:18Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+  let arguments = (ins
+                   Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);
+
+  let results = (outs CIR_PtrToVPtr:$vptr_ty);


This is actual pointer result not a type, so $result or $vptr or $results_vptr is more appropriate name.

Suggested change

let results = (outs CIR_PtrToVPtr:$vptr_ty);

let results = (outs CIR_PtrToVPtr:$result);

xlauko · 2025-07-31T19:46:40Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+    The `vtable.get_virtual_fn_addr` operation retrieves the address of a
+    virtual function pointer from an object's vtable (__vptr).
+    This is an abstraction to perform the basic pointer arithmetic to get
+    the address of the virtual function pointer, which can then be loaded and
+    called.


Maybe reference relation to !cir.vptr here.

xlauko · 2025-07-31T19:56:53Z

clang/include/clang/CIR/Dialect/IR/CIRTypeConstraints.td

+def CIR_AnyVPtrType : CIR_TypeBase<"::cir::VPtrType",
+    "vptr type">;


Suggested change

def CIR_AnyVPtrType : CIR_TypeBase<"::cir::VPtrType",

"vptr type">;

def CIR_AnyVPtrType : CIR_TypeBase<"::cir::VPtrType", "vptr type">;

xlauko · 2025-07-31T20:03:16Z

clang/include/clang/CIR/Dialect/IR/CIROps.td

+  let builders = [
+    OpBuilder<(ins "mlir::Type":$type,
+                   "mlir::Value":$value,
+                   "unsigned":$index),
+    [{
+      mlir::APInt fnIdx(64, index);
+      build($_builder, $_state, type, value, fnIdx);
+    }]>
+  ];
+
+  let extraClassDeclaration = [{
+    /// Return the index of the record member being accessed.
+    uint64_t getIndex() { return getIndexAttr().getZExtValue(); }
+  }];


If you change type of $index from IndexAttr to I64Attr in arguments these all can be deleted, as it will auto generate getIndex returning underlying uint64_t and is buildable from unsigned.

This is also a nice improvement. I was following the example of GetMemberOp and a few others, which can also be cleaned up in the way you suggest.

xlauko · 2025-07-31T20:03:57Z

clang/include/clang/CIR/Dialect/IR/CIRTypes.td

+def CIR_VPtrType : CIR_Type<"VPtr", "vptr",
+    [DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {
+


Suggested change

def CIR_VPtrType : CIR_Type<"VPtr", "vptr",

[DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {

def CIR_VPtrType : CIR_Type<"VPtr", "vptr", [

DeclareTypeInterfaceMethods<DataLayoutTypeInterface>

]> {

xlauko · 2025-07-31T20:07:15Z

clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp

-          cir::AddressPointAttr::get(CGF.getBuilder().getContext(), 0,
-                                     VTableIndex));
+      auto VTableSlotPtr =
+          CGF.getBuilder().create<cir::VTableGetVirtualFnAddrOp>(


nit: add auto &builder = CGM.getBuilder(); at top of the function to clean up multiple uses of the builder

xlauko · 2025-07-31T20:14:22Z

clang/lib/CIR/Dialect/IR/CIRDialect.cpp

-  auto fnTy = cir::FuncType::get({}, intTy);
-
-  auto resTy = cir::PointerType::get(cir::PointerType::get(fnTy));
+  auto resTy = cir::PointerType::get(cir::VPtrType::get(getContext()));

  if (resultType != resTy)


nit: I suggest to add let cppFunctionName = "isPtrToVPtrType"; into CIR_PtrToVPtr constraint which can be used in places like this if (isPtrToVPtrType(resultType)) without need to explicitly construct cir::PointerType::get(cir::VPtrType::get(getContext())); before.

I don't think this is even needed here, since the return type is now encoded as CIR_PtrToVPtr in the op definition, but I'll keep this tip in mind for future uses.

andykaylor · 2025-08-01T16:21:47Z

I've addressed the feedback from @xlauko. I do intend to add the examples that @tommymcm suggested, but I'd like to do that in a follow-up PR.

xlauko

lgtm

This change introduces a new type, cir.vtable, to be used with operations that return a pointer to a class' vtable.

andykaylor · 2025-08-01T19:54:36Z

I realized while creating the examples that I had an extra level of indirection in the return value of cir.vtable.address_point. The value returned by this operation is stored in the class record during the constructor, but the corresponding entry in the record is a cir.vptr, not a !cir.ptr<!cir.vptr> so cir.vtable.address_point must return cir.vptr.

I'll be posting an update to fix that shortly.

bcardosolopes

Thanks for improving this, neat! I don't have much else to add on top of existing comments - LGTM pending your latest findings.

This PR is inspired by the discussion in #1745 (comment). When changing the type of ```mlir IndexAttr:$index, I64Attr:$index ``` in `GetMemberOp`, the `getIndex` method becomes auto-generated. This allows us to remove the custom builder previously defined for this operation.

andykaylor requested review from xlauko, bcardosolopes, erichkeane and lanza July 15, 2025 20:35

erichkeane approved these changes Jul 15, 2025

View reviewed changes

xlauko reviewed Jul 16, 2025

View reviewed changes

lanza force-pushed the main branch 2 times, most recently from d2c4ab8 to 8f89224 Compare July 23, 2025 17:04

andykaylor force-pushed the cir-vtable-type branch from a0aca63 to 0be2244 Compare July 30, 2025 17:44

andykaylor requested review from xlauko and erichkeane July 30, 2025 17:45

andykaylor changed the title ~~[CIR] Add special type for vtables~~ [CIR] Add special type and new operations for vptrs Jul 30, 2025

andykaylor mentioned this pull request Jul 30, 2025

[CIR] Add vptr type and generate vptr field when needed llvm/llvm-project#151377

Merged

Lancern reviewed Jul 31, 2025

View reviewed changes

xlauko reviewed Jul 31, 2025

View reviewed changes

xlauko approved these changes Aug 1, 2025

View reviewed changes

andykaylor added 5 commits August 1, 2025 11:02

[CIR] Add special type for vtables

e8ba80a

This change introduces a new type, cir.vtable, to be used with operations that return a pointer to a class' vtable.

Add vtable.get_virtual_fn_addr and vtable.get_vptr

e41f779

Cleanup test case

9200392

Address review feedback

4a96555

Update delete.cpp test after rebase

48461c5

andykaylor force-pushed the cir-vtable-type branch from 15b8c9f to 48461c5 Compare August 1, 2025 18:15

Remove an extra level of indirection on cir.vtable.address_point

3f7dee0

andykaylor requested a review from xlauko August 1, 2025 20:17

bcardosolopes approved these changes Aug 7, 2025

View reviewed changes

andykaylor merged commit 942008c into llvm:main Aug 7, 2025
6 of 9 checks passed

andykaylor deleted the cir-vtable-type branch August 7, 2025 17:27

Andres-Salamanca mentioned this pull request Aug 13, 2025

[CIR][NFC] Change GetMemberOp index type #1811

Merged

		def CIR_AnyVTableType : CIR_TypeBase<"::cir::VTableType",
		"vtable type">;

		def CIR_VTableType : CIR_Type<"VTable", "vtable",
		[DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {

		let arguments = (ins
		Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);

		Arg<CIR_PointerType, "the vptr address", [MemRead]>:$src);

		let results = (outs CIR_PtrToVPtr:$vptr_ty);

	let results = (outs CIR_PtrToVPtr:$vptr_ty);
	let results = (outs CIR_PtrToVPtr:$result);

		def CIR_AnyVPtrType : CIR_TypeBase<"::cir::VPtrType",
		"vptr type">;

		def CIR_VPtrType : CIR_Type<"VPtr", "vptr",
		[DeclareTypeInterfaceMethods<DataLayoutTypeInterface>]> {

[CIR] Add special type and new operations for vptrs #1745

[CIR] Add special type and new operations for vptrs #1745

Uh oh!

Conversation

andykaylor commented Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xlauko left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andykaylor commented Jul 16, 2025

Uh oh!

andykaylor commented Jul 30, 2025

Uh oh!

tommymcm commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

andykaylor commented Jul 30, 2025

Uh oh!

tommymcm commented Jul 30, 2025

Uh oh!

Lancern Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xlauko left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xlauko Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andykaylor commented Aug 1, 2025

Uh oh!

xlauko left a comment

Choose a reason for hiding this comment

Uh oh!

andykaylor commented Aug 1, 2025

Uh oh!

bcardosolopes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

andykaylor commented Jul 15, 2025 •

edited

Loading

xlauko left a comment •

edited

Loading

tommymcm commented Jul 30, 2025 •

edited

Loading

Lancern Jul 31, 2025 •

edited

Loading

xlauko Jul 31, 2025 •

edited

Loading