<div dir="ltr">Today, the vast majority of target in Clang coerce aggregates passed this way into appropriate word-sized types. They all use their own custom heuristics to compute the LLVM types used for the coercions. It's terrible, but this is the current consensus.<div><br></div><div>I would like to improve the situation so that passing LLVM aggregates directly does the right thing when the LLVM struct type and C struct type are effectively the same, so that custom frontend lowering is required for hard cases involving things like _Complex and unions.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 7, 2017 at 9:42 AM, Alex Bradbury via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As many of you will know, handling of struct arguments in LLVM is<br>
actually slightly more fiddly than you might expect. For targets where<br>
aggregates are always passed on the stack it's easy enough, the Clang<br>
ABI code marks these arguments as byval and the call lowering code in<br>
LLVM will copy the object to the stack when needed. There are more<br>
options for when the target has more complex ABI rules, e.g. that as<br>
much of a struct that will fit should be passed in argument registers.<br>
One option is to let Clang (or the frontend of your choice) mark the<br>
argument as byval, but then have the LLVM call lowering code assign<br>
registers where possible. Alternatively, you can alter the frontend's<br>
ABI handling so it decomposes the struct for you - the challenge being<br>
ensuring that the appropriate packing/alignment is maintained. Because<br>
of this for some targets byval does mean "pass on the stack", but not<br>
others.<br>
<br>
There's been some discussion of this issue previously:<br>
* In the context of PowerPC, which will coerce structs below a certain<br>
size to an integer array<br>
<<a href="http://lists.llvm.org/pipermail/llvm-dev/2015-March/083554.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2015-March/<wbr>083554.html</a>><br>
* Previous suggestions that we really want an "onstack" attribute<br>
<<a href="http://lists.llvm.org/pipermail/llvm-dev/2012-May/049406.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2012-May/<wbr>049406.html</a>><br>
<br>
I'm working with a calling convention<br>
(<a href="https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md" rel="noreferrer" target="_blank">https://github.com/riscv/<wbr>riscv-elf-psabi-doc/blob/<wbr>master/riscv-elf.md</a>)<br>
where structs of up to two words in length should be passed in<br>
registers, but otherwise on the stack (EXCEPT in the case where there<br>
is only one argument register left, in which case the struct is split<br>
between that register and the stack).<br>
<br>
Is there a consensus now on how this should be handled?<br>
<br>
Thanks,<br>
<br>
Alex<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>