• 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

Johan Engelen <j j.nl> writes:

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

"David Nadlinger" <code klickverbot.at> writes:

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