[llvm-dev] Current preferred approach for handling 'byval' struct arguments
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Tue Mar 7 09:42:10 PST 2017
As many of you will know, handling of struct arguments in LLVM is
actually slightly more fiddly than you might expect. For targets where
aggregates are always passed on the stack it's easy enough, the Clang
ABI code marks these arguments as byval and the call lowering code in
LLVM will copy the object to the stack when needed. There are more
options for when the target has more complex ABI rules, e.g. that as
much of a struct that will fit should be passed in argument registers.
One option is to let Clang (or the frontend of your choice) mark the
argument as byval, but then have the LLVM call lowering code assign
registers where possible. Alternatively, you can alter the frontend's
ABI handling so it decomposes the struct for you - the challenge being
ensuring that the appropriate packing/alignment is maintained. Because
of this for some targets byval does mean "pass on the stack", but not
others.
There's been some discussion of this issue previously:
* In the context of PowerPC, which will coerce structs below a certain
size to an integer array
<http://lists.llvm.org/pipermail/llvm-dev/2015-March/083554.html>
* Previous suggestions that we really want an "onstack" attribute
<http://lists.llvm.org/pipermail/llvm-dev/2012-May/049406.html>
I'm working with a calling convention
(https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md)
where structs of up to two words in length should be passed in
registers, but otherwise on the stack (EXCEPT in the case where there
is only one argument register left, in which case the struct is split
between that register and the stack).
Is there a consensus now on how this should be handled?
Thanks,
Alex
More information about the llvm-dev
mailing list