<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 29, 2016 at 6:24 AM, Nirav Davé <span dir="ltr"><<a href="mailto:niravd@google.com" target="_blank">niravd@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. </div></blockquote><div><br></div><div>It's not that simple, though. Consider this code:</div><div>struct X { int x; };</div><div>int f(int a, struct X b, int c) { return a + b.x + c; }</div><div><br></div><div>Clang uses this LLVM prototype for f:</div><div>define i32 @j(i32 inreg %a, i32 %b.0, i32 inreg %c)<br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div>define x86_regparm_3 i32 @j(i32 %a, %struct.X* byval %b, i32 %c)<br></div><div><br>Maybe that's just the point, though. We should add an 'onstack' attribute, and force uncommon cases to use weird attributes. :)</div><div><br></div><div>So, go for it I guess.</div></div></div></div>