LLVM will move to "opaque pointers" in the future

[David Nadlinger]

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