<div dir="ltr"><div>Thanks for the explanation. It's good to hear the situation isn't felt to be ideal.</div><div><br></div><div>The details here are going to be sensitive to the OS + target that I'm compiling for, right? So the effort here will be to understand and get right the calling convention details for each supported target, yes?</div><div><br></div><div>Is there any current plan to change the way this works, or is it more of a dreamy cleanup item that maybe will get addressed some day?</div><div><br></div><div>Appreciate the tip.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 28, 2016 at 9:28 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27 March 2016 at 21:48, Michael Nicolella via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Can someone help me understand why this detail needs to be understood by the frontend,<br>
<br>
</span>Many of the backends can do automatic demotion to sret, but the<br>
front-end still needs to be aware of the issues (particularly around<br>
unions, since whether demotion is necessary can depend on more than<br>
just the size of the type).<br>
<br>
I'd also expect marginally better code in some cases by using sret<br>
explicitly: the demotion occurs pretty late on and a "%type *sret"<br>
parameter better represents what will actually be happening later on.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>