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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
