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

[Rik Huijzer via flang-commits]

rikhuijzer wrote:

> What are the use cases for allowing either of these two syntaxes?
> The LLVM Dialect tries to closely mirror LLVM proper as much as possible and this would deviate from LLVMs behaviour. While the transition is currently stalled, in the future typed pointers will be removed from the dialect entirely, further discouraging the use of typed-pointers such as shown here.

>From reading <https://reviews.llvm.org/D123310>, I assume that the use-case is that "MLIR can afford to support both opaque and non-opaque pointers at the same time and simplify the transition". But Alex (@ftynse) is probably the best person to answer this.

Regardless of the big picture, the question might be unrelated to this PR as this PR only fixes a bug in the implementation. Currently, there are LLVM operations in MLIR that do accept both forms. For example, `llvm.alloca` where

```mlir
llvm.func @main(%sz : i64) {
  "llvm.alloca"(%sz) : (i64) -> !llvm.ptr<i32>
  llvm.return
}
```

and 

```mlir
llvm.func @main(%sz : i64) {
  "llvm.alloca"(%sz) { elem_type = i32 } : (i64) -> !llvm.ptr
  llvm.return
}
```
Both are translated to
```llvm
; ModuleID = 'LLVMDialectModule'
source_filename = "LLVMDialectModule"

declare ptr @malloc(i64)

declare void @free(ptr)

define void @main(i64 %0) {
  %2 = alloca i32, i64 %0, align 4
  ret void
}

!llvm.module.flags = !{!0}

!0 = !{i32 2, !"Debug Info Version", i32 3}
```
via
```sh
mlir-translate temp.mlir -mlir-to-llvmir
```
Conversely, `llvm.getelementptr` currently only accepts the attribute (`{ elem_type = !llvm.ptr }`). This PR makes things consistent again.

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