fhahn
September 16, 2025, 5:44pm
72
Back up your claims. To build consensus, avoid weasel words: “long in the making”, “widely discussed”, “clear net positive”. We need more “specifics” not ambiguity.
Just looking through the archive, here are some RFC threads, spanning 2019-2022. I didn’t go back further, but the 2019 one is an update on the current status, there’s been more discussions before that as well.
Hi all,
At the dev meeting I promised to update everyone on where my work with opaque
pointers is right now. It’s taken me a while, but at least it’s the same year!
Current Status
I’ve put two branches up at https://github.com/TNorthover/llvm-project :
“opaque-ptr” which has most of the real work so far; and “opaque-ptr-always”
that additionally has a patch to force every pointer to be opaque and see what
falls over. It’s about 40 patches on top of master in a few categories.
Serializati…
As part of the opaque pointers migration , we need to make the clang frontend not depend on PointerType’s pointee type. There are a couple random places that need to be fixed up to not use PointerType::getElementType and Type::getPointerElementType(), but the biggest issue is (I believe) clang::CodeGen::Address (and LValue/RValue?).
I had a very preliminary attempt in https://reviews.llvm.org/D103465 but am not super familiar with the clang frontend. Is there anybody more familiar with clang who…
Hi everyone,
During the transition to opaque pointers (see https://llvm.org/docs/OpaquePointers.html for context) a somewhat recurring issue is the choice of source element types for getelementptr instructions. Consider these two GEPs:
getelementptr [[i32 x 10], x 10], ptr %p, i64 0, i64 1, i64 0
getelementptr i8, ptr %p, i64 40
If I counted correctly, these two GEPs perform the same address calculation. With typed pointers, they differed in their source and result pointer types. With opaque…
LLVM is currently in the process of migrating towards opaque pointers. Opaque Pointers — LLVM 16.0.0git documentation has some documentation for this migration, but the TL;DR is that pointers like i32* are being replaced with an opaque pointer type ptr. You can test opaque pointers today by passing -opaque-pointers to opt or -mllvm -opaque-pointers to clang.
We have recently reached a milestone where it is possible to compile most C/C++ code, with or without optimization, in opaque pointer mode…
Since the last status update the opaque pointer migration has reached the point where both LLVM and Clang fully support opaque pointers (modulo some minor pending patches). I think it is time to talk about enabling opaque pointers by default.
The core problem with enabling opaque pointers is that they have major impact on tests: At least any tests with pointer types in their CHECK lines will have different output when opaque pointers are enabled (even if the difference is only cosmetic). As a r…
For background on opaque pointer types, see 1 and many other patches/threads searchable with “opaque pointers”.
While there’s been lots of work around making opaque pointers work, we don’t actually have a type like that in LLVM yet. https://reviews.llvm.org/D101704 introduces the opaque pointer type within LLVM so we can start playing around with the opaque pointer type and see what goes wrong. Much of the patch above is based on TNorthover’s branch from a couple years ago 2 .
The opaque pointe…
5 Likes