digitalmars.D.ldc - LLVM will move to "opaque pointers" in the future
- Johan Engelen (32/32) May 18 2021 Hi all,
- David Nadlinger (7/37) May 19 2021 Thanks for pointing this out. I can't see any major issues in switching
Hi all, FYI: https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst Instead of having to specify the type of the data pointed too "i8*", "ptr" just says it's a pointer. This prevents a bunch of bitcasts in the IR (which LDC also often has to do). But it also means we can no longer rely on an LLVM IR to contain type information, for example when we generate a GEP: ```cpp llvm::GetElementPtrInst *DtoGEP(LLValue *ptr, llvm::ArrayRef<LLValue *> indices, const char *name, llvm::BasicBlock *bb) { LLPointerType *p = isaPointer(ptr); auto gep = llvm::GetElementPtrInst::Create(p->getElementType(), ... // the p->getElementType() will no longer work somewhere in the future ``` From the LLVM document: Frontend Migration Steps If you have your own frontend, there are a couple of things to do after opaque pointer types fully work. Don't rely on LLVM pointee types to keep track of frontend pointee types Migrate away from LLVM IR instruction builders that rely on pointee types For example, IRBuilder::CreateGEP() has multiple overloads; make sure to use one where the source element type is explicitly passed in, not inferred from the pointer operand pointee type cheers, Johan
May 18 2021
Thanks for pointing this out. I can't see any major issues in switching over on our side, but I do wonder how the transition period is going to look – I guess this will depend in a major fashion on whether upstream is going to offer a cross-compatible interface for all the relevant APIs for the versions before/after the transition. — David On 18 May 2021, at 17:06, Johan Engelen via digitalmars-d-ldc wrote:Hi all, FYI: https://github.com/llvm/llvm-project/blob/main/llvm/docs/OpaquePointers.rst Instead of having to specify the type of the data pointed too "i8*", "ptr" just says it's a pointer. This prevents a bunch of bitcasts in the IR (which LDC also often has to do). But it also means we can no longer rely on an LLVM IR to contain type information, for example when we generate a GEP: ```cpp llvm::GetElementPtrInst *DtoGEP(LLValue *ptr, llvm::ArrayRef<LLValue *> indices, const char *name, llvm::BasicBlock *bb) { LLPointerType *p = isaPointer(ptr); auto gep = llvm::GetElementPtrInst::Create(p->getElementType(), ... // the p->getElementType() will no longer work somewhere in the future ``` From the LLVM document: Frontend Migration Steps If you have your own frontend, there are a couple of things to do after opaque pointer types fully work. Don't rely on LLVM pointee types to keep track of frontend pointee types Migrate away from LLVM IR instruction builders that rely on pointee types For example, IRBuilder::CreateGEP() has multiple overloads; make sure to use one where the source element type is explicitly passed in, not inferred from the pointer operand pointee type cheers, Johan
May 19 2021