[llvm-dev] Current preferred approach for handling 'byval' struct arguments

[James Y Knight via llvm-dev]

On Mon, Mar 20, 2017 at 11:54 AM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, Mar 18, 2017 at 8:37 AM, Alex Bradbury <asb at asbradbury.org> wrote:
>
>> In the RISC-V calling convention, large scalars (larger than 2 GPRs)
>> are passed indirect, just like large aggregates. e.g. an i128 or a
>> long double on a 32-bit platform. It's tempting to let the frontend
>> emit i128 and fp128 arguments/return values, however making the
>> argument indirect is somewhat easier in the frontend.
>
>
> 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.
>
> Of course, there are many drawbacks to the current split of
> responsibilities, so it's definitely a tradeoff.
>

I agree that's how it is right now, but that tradeoff doesn't sound
intrinsic to the problem.

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170320/09fb36d5/attachment.html>