[Mlir-commits] [mlir] [mlir][LLVM] Improve lowering of `llvm.byval` function arguments (PR #100028)

[Diego Caballero]

dcaballe wrote:

> Isn't there a problem with the way `llvm.byval` seems modeled here: why is this something that annotating before the lowering instead of a property of the type you lower? 

Good point! There are a few aspects related to this: 

* There seems to be multiple users of this “pre-lowering annotation” approach, including FIR and probably some downstreams, which goes beyond the `llvm.byval` case. We can see how a few attributes are processed [here](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp#L353-L369) and they are not inserted by the LLVM lowering itself. In some cases, this is probably an attempt at reusing those attributes in other dialects before LLVM. 

* This `llvm.byval` mechanism seems very specific to LLVM. A dialect that is eventually lowered to LLVM (or any other egress dialect) may model a pass-by-value of a non-ptr type by just passing an SSA value of that type. Unfortunately, if that type is lowered to an aggregate type in LLVM, the pass-by-value will have to go through the `llvm.byval` mechanism, which requires passing an `llvm.ptr` instead of the actual aggregate type. To me, this looks like an LLVM ABI requirement more than a property of the type lowered to LLVM. 

* The `llvm.byval` mechanism can also be used for non-aggregate types (not sure why we would use it instead of just passing the non-aggregate type directly). This makes the previous bullet also applicable to non-aggregate types. 

I’m planning to follow up on this and automatically introduce the `llvm.byval` attributes for aggregate type arguments. However, that won’t solve the problem for non-aggregate types and other LLVM attributes that are currently introduced before the lowering.


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