[Mlir-commits] [mlir] [MLIR][LLVM] Tail call support for inline asm op (PR #140826)

[Christian Ulmann]

================
@@ -2298,13 +2298,18 @@ def LLVM_InlineAsmOp : LLVM_Op<"inline_asm", [DeclareOpInterfaceMethods<MemoryEf
     written, or referenced.
     Attempting to define or reference any symbol or any global behavior is
     considered undefined behavior at this time.
+    If `tail_call_kind` is used, the operation behaves like the specified
+    tail call kind. The `musttail` kind it's not available for this operation,
+    since it isn't supported by LLVM's inline asm.
   }];
   let arguments = (
     ins Variadic<LLVM_Type>:$operands,
         StrAttr:$asm_string,
         StrAttr:$constraints,
         UnitAttr:$has_side_effects,
         UnitAttr:$is_align_stack,
+        OptionalAttr<
+        DefaultValuedAttr<TailCallKind, "TailCallKind::None">>:$tail_call_kind,
----------------
Dinistro wrote:

But now we once again have two ways of modelling the same state, which is something that can be a bit messy to deal with.
According to the doc (https://mlir.llvm.org/docs/DefiningDialects/Operations/#attributes-with-default-values):
> The generated operation printing function will not print default-valued attributes when the attribute value is equal to the default.

If that doesn't work in this case, then the assembly format is probably broken in some way.

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