[llvm-dev] Using "opaque pointers" right now?

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 16 01:27:57 PST 2019

Hi Christoffer,

On Mon, 16 Dec 2019 at 00:03, Christoffer Lernö via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other way to perpare for this change?

The main one is to make sure you avoid using getElementType on
pointers. If you're writing a front-end this probably means you need
to keep your AST's representation of element types alongside LLVM
pointer Values in your own data-structures (beware, llvm::Type may not
be enough if that contains nested pointers). That lets you pass them
into the instructions that will need it (loads, GEPs, allocas etc).

> And also - is it possible to use something like opaque pointers (that is using a single pointer type) even before the switch has been flipped in LLVM?

Not in current LLVM. I have a branch that has some work on them. I've
been meaning to upload, document and propose a real path forwards on
llvm-dev but other things have gotten in the way up to now. I think
there's quite a bit of infrastructure work just to make the bitcode
and IR layers accept opaque pointers, and after that many passes and
other components assert when they first encounter an opaque pointer.

I've not managed to fix all of those yet so I'm still a bit unsure how
things will work then, but I'd expect at least some correctness and
performance regressions to begin with. I'm hoping that work can happen
incrementally and during this phase I hope people would be able to
experiment and make sure they're ready.



More information about the llvm-dev mailing list