It looks like the direct reason is that, MLIR doesn't offer mlir::LLVM::VAArgOp in mlir/include/mlir/Dialect/LLVMIR/LLVMIntrinsicOps.td while it offers mlir::LLVM::VaStartOp, mlir::LLVM::VaEndOp and mlir::LLVM::VaCopyOp. So if we want to support va_arg in CIR, we have to touch the different targets. Do I understand the problem correctly?

And if yes, it looks like we can't use llvm's va-arg-instruction directly due to some layering issues. I am wondering if we can make it by adding these layers in CIR. Since I don't feel it is right to handle these architecture specific things in CIR. It should be the job of LLVM.

Sent #865

Since I don't feel it is right to handle these architecture specific things in CIR. It should be the job of LLVM.

To give some extra context: YMMV here, somethings are lowered early and some of them late in the pipeline, it depends on a number of factors. Example: out of CIRGen we have some layers for vtable access while for some types (like doubles) we impose their underlying ABI widths early. Calling convention lowering is a mid pipeline example: it's done CIR to CIR before LLVM lowering, since we don't want to reconstruct things if we are doing analysis that require some level of source fidelity. The decision is usually made considering potential (or more concrete) use cases, with a special care not to over design anything that we don't have a use case for.

For the vaarg in question, your direction sounds good, thanks for working on this. @sitio-couto since you have the most fresh context in this area, anything you'd like to comment?

It looks like the direct reason is that, MLIR doesn't offer mlir::LLVM::VAArgOp in mlir/include/mlir/Dialect/LLVMIR/LLVMIntrinsicOps.td while it offers mlir::LLVM::VaStartOp, mlir::LLVM::VaEndOp and mlir::LLVM::VaCopyOp. So if we want to support va_arg in CIR, we have to touch the different targets. Do I understand the problem correctly?

Yes, It was a reason I had to do ABI specific lowering in CIR Lowering Prepare for var_arg. Another reason is that clang codegen does ABI-specific lowering, and not lowering to llvm var_arg instruction, probably for a good reason.

There were discussions and concerns about the instruction in the past.
https://lists.llvm.org/pipermail/llvm-dev/2017-August/116337.html
https://discourse.llvm.org/t/va-arg-on-windows-64/40780

And if yes, it looks like we can't use llvm's va-arg-instruction directly due to some layering issues. I am wondering if we can make it by adding these layers in CIR. Since I don't feel it is right to handle these architecture specific things in CIR. It should be the job of LLVM.

In general, I agree with your direction. For this matter, better if CIR leaves the ABI specific implementation to LLVM backend. But that being said, we need to have trust that llvm var_arg instruction has reliable and good support for ABIs.
See current clang llvm is not using va_arg instruction
https://godbolt.org/z/1bTK11cMn

Thanks for bringing this into attention @ghehg, I didn't recall that Clang wasn't really using this instruction, good catch.

we need to have trust that llvm var_arg instruction has reliable and good support for ABIs. See current clang llvm is not using va_arg instruction: https://godbolt.org/z/1bTK11cMn

+1, we need to lower to very similar code, summary of this discussions so far:

• OG codegen lower early because ABI is hard, does not use var_arg.
• LLVM code coming from CIR should be very similar to OG.
• x86_64 support for var_arg should be implemented in target lowering, similar to like we do for aarch64. If it's similar to x86_64 perhaps it should be refactor to the default or whatever makes more sense.

Fine enough. I'll try to use the patch in the downstream first and go back to implement it as we like after I have a better understanding of the problem scope.

FWIW, we don't need that operation in LLVM IR dialect for the sake of ClangIR lowering, since the desired approach has already been discusses here and in the PR.

FWIW, we don't need that operation in LLVM IR dialect for the sake of ClangIR lowering, since the desired approach has already been discusses here and in the PR.

Practically, yet. But technically, the LLVM IR dialect is still required by some other targets.