================
@@ -3415,4 +3415,81 @@ def CIR_FAbsOp : CIR_UnaryFPToFPBuiltinOp<"fabs",
"FAbsOp"> {
}];
}
+//===----------------------------------------------------------------------===//
+// Variadic Operations
+//===----------------------------------------------------------------------===//
+
+def CIR_VAStartOp : CIR_Op<"va.start"> {
+ let summary = "Starts a variable argument list";
+ let description = [{
+ The cir.va.start operation models the C/C++ va_start macro by
+ initializing a variable argument list at the given va_list storage
+ location.
+
+ The operand must be a pointer to the target's `va_list` representation.
+ This operation has no results and produces its effect by mutating the
+ storage referenced by the pointer operand.
+
+ Each `cir.va.start` must be paired with a corresponding `cir.va.end`
+ on the same logical `va_list` object along all control-flow paths. After
+ `cir.va.end`, the `va_list` must not be accessed unless reinitialized
+ with another `cir.va.start`.
+
+ Lowering typically maps this to the LLVM intrinsic `llvm.va_start`,
----------------
mmha wrote:
My mind was at "What if we don't lower to LLVM?". I removed the "typically".
The LLVM intrinsic has a few problems because it's not a complete solution and
sometimes generates worse code which is why classic codegen only uses it as a
default in its ABI lowering. See
[here](https://discourse.llvm.org/t/varargs-the-x86-and-clang/38354) or
[here](https://lists.llvm.org/pipermail/llvm-dev/2017-August/116337.html).
In #153834 I added lowering to `llvm.va_arg` as a default in LowerToLLVM. Once
we get proper ABI lowering in LoweringPrepare (or at a similar stage) upstream
a target can replace `cir.va_arg` with something else. But for now this is a
good stopgap to enable things like scalar varargs on most platforms.
https://github.com/llvm/llvm-project/pull/153819
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
