[flang-commits] [flang] [mlir][llvm] Fix elem type passing into `getelementptr` (PR #68136)

[Markus Böck via flang-commits]

zero9178 wrote:

Thank you for your elaboration!
I am not sure whether the original commit is referring to also supporting both typed pointers and opaque pointers in the exact same IR. This behaviour deviates from LLVM entirely as LLVM only supported one or the other as well.

Furthermore, your example of the alloca is not quite equivalent to the GEP. Your first example uses strictly typed pointers while the second uses strictly opaque pointers. The GEP `llvm.getelementptr %0[0] : (!llvm.ptr) -> !llvm.ptr<ptr>` mixes both opaque pointers and typed pointers, which has so far not been supported.
Note that: `llvm.getelementptr %0[0] : (!llvm.ptr) -> !llvm.ptr, !llvm.ptr` and `llvm.getelementptr %0[0] : (!llvm.ptr<ptr>) -> !llvm.ptr<ptr>` work without issues.

Lastly, the PR also deviates from how GEPs works with typed pointers as it deduces the element type from the result pointer. If we really want to support a half-typed half-opaque GEP it'd make more sense to support `llvm.getelementptr %0[0] : (!llvm.ptr<ptr>) -> !llvm.ptr`. This would also allow specifying more than one index, something the current solution doesn't. E.g.
```
`llvm.getelementptr %0[0, 1] : (!llvm.ptr<struct<(i32, i8)>>) -> !llvm.ptr`
```

With all that said, I see this more as a "potential missing feature" rather than a bug. That is why I am curious what the motivation here is. Is this to ease transition to opaque pointers? I am not sure how effective this would be and I am a bit afraid of the burden of having to maintain what is essentially a third GEP representation.

https://github.com/llvm/llvm-project/pull/68136