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