[PATCH] D27050: [X86] Add explicit regparm flag for X86-32 calling convention.

[Reid Kleckner via llvm-commits]

On Tue, Nov 29, 2016 at 6:24 AM, Nirav Davé <niravd at google.com> wrote:

> I agree that we by the end of this we should be able to remove inreg (at
> least from integer parameters). My hesistation is that it's not just the C
> convention that we need to list, it's also stdcall, fastcall, vectorcall,
> (and potentially intel_ocl_bi though I think not). If we need to do the
> same for  "-msseregparm" this would be the majority of llvm calling
> conventions. Function attributes would keep the number smaller, but perhaps
> this isn't such a big deal if these are the only variants.
>

It's not that simple, though. Consider this code:
struct X { int x; };
int f(int a, struct X b, int c) { return a + b.x + c; }

Clang uses this LLVM prototype for f:
define i32 @j(i32 inreg %a, i32 %b.0, i32 inreg %c)

Because %b.0 lacks inreg, it knows that %b.0 goes on the stack. We'd have
to encode that some other way if we wanted to get rid of inreg. Even if you
use __fastcall in MS mode, you get these inreg attributes for the same
reason.

We go to a lot of trouble to decompose structs into integer types for a
reason. It generates better code. This is the "obvious" new lowering in
your scheme, but the extra pointer indirection is bad news for the
optimizer:
define x86_regparm_3 i32 @j(i32 %a, %struct.X* byval %b, i32 %c)

Maybe that's just the point, though. We should add an 'onstack' attribute,
and force uncommon cases to use weird attributes. :)

So, go for it I guess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161129/b9f3cee1/attachment.html>