<div>Hi Tim:</div><div>Thanks for the input. I guess we have to handle each arch individually using the Module's Triple now.</div><div>But how exactly do those differ? By Vendor?By Arch or by OS? I'm planning on writing a giant switch with the Target triple but I'm not entirely sure which element I should be switching upon : (.</div><div><br></div><div>Zhang</div><div><includetail><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Tim Northover"<t.p.northover@gmail.com>;</div><div><b>Date: </b> Wed, Jul 18, 2018 04:27 PM</div><div><b>To: </b> "admin"<admin@mayuyu.io>; <wbr></div><div><b>Cc: </b> "LLVM Developers Mailing List"<llvm-dev@lists.llvm.org>; <wbr></div><div><b>Subject: </b> Re: [llvm-dev] Why Clang is unpacking my StructType Function arguments</div></div><div> </div><div style="position:relative;">Hi Zhang,<br><br>On Wed, 18 Jul 2018 at 09:06, Zhang via llvm-dev<br><llvm-dev@lists.llvm.org> wrote:<br>> It would be great if someone could tell me how to tell clang from unpacking my arguments and if that's not possible , the correct way to handle this diffrence.<br><br>There's no way to control this I'm afraid. The issue is that each<br>platform has an ABI document that specifies in detail where arguments<br>have to be passed in registers and on the stack. LLVM IR isn't really<br>detailed enough to represent all of these nuances properly.<br>Especially, you can't always just use the struct type itself or you'll<br>be incompatible with other compilers and libraries.<br><br>So there is unfortunately a hidden contract between Clang and each<br>backend: Clang (in lib/CodeGen/TargetInfo.cpp) knows how each backend<br>will treat simple parameters and does things like the splitting up<br>you've seen, and adding unused padding arguments to make sure the<br>arguments go where they should. And because this kind of effort is<br>sometimes needed, it's viewed as a pretty low priority to preserve the<br>type where it would be sufficient. Correctness is the most important<br>metric, after all.<br><br>It's not an ideal situation and there's been talk in the past of<br>moving some of that logic into a utility library in LLVM itself, or<br>even enhancing LLVM IR to handle it more elegantly, but nothing has<br>come of it yet I'm afraid so at the moment you have to either<br>duplicate that kind of logic yourself or use Clang as some kind of<br>library to do it for you (I'm not sure of the details, but I believe<br>Swift takes this approach).<br><br>Cheers.<br><br>Tim.<br></div></div><!--<![endif]--></includetail></div>