<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 20, 2017 at 11:54 AM, Reid Kleckner 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Sat, Mar 18, 2017 at 8:37 AM, Alex Bradbury <span dir="ltr"><<a href="mailto:asb@asbradbury.org" target="_blank">asb@asbradbury.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the RISC-V calling convention, large scalars (larger than 2 GPRs)<br>
are passed indirect, just like large aggregates. e.g. an i128 or a<br>
long double on a 32-bit platform. It's tempting to let the frontend<br>
emit i128 and fp128 arguments/return values, however making the<br>
argument indirect is somewhat easier in the frontend.</blockquote><div><br></div></span><div>This is a great example for why the responsibilities are currently weirdly split between the frontend and backend. The more ABI lowering you do in the frontend, the more information is available for the mid-level optimizer to hack on. If the backend was responsible for creating a temporary i128 value in memory and taking its address, the mid-level would never have an opportunity to optimize those memory loads and stores, or realize that the callee never modifies its argument, making the copy is unnecessary.</div><div><br></div><div>Of course, there are many drawbacks to the current split of responsibilities, so it's definitely a tradeoff.</div><div></div></div></div></div></blockquote><div><br></div><div>I agree that's how it is right now, but that tradeoff doesn't sound intrinsic to the problem.</div><div><br></div><div>A transform from highish-level function ABI to low-level function ABI could be done entirely within LLVM as an early target-specific pass, if that's necessary for performance. It doesn't need to be pushed all the way up into the frontend!</div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></div><br></div></div>