<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><br><div><div><div><div><div>-Nirav<br><div><br></div><div><div><div><div><br></div><div><br><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 3:33 PM, James Y Knight via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jyknight added a comment.<br>
<br>
There's two cases:<br>
<br>
1. The calling convention for functions named in the IR. This can be set separately for each function by the frontend. Today, it's done by putting "inreg" attributes on appropriate parameters.<br>
2. The calling convention used for library calls generated by LLVM. Today, this is not handled.<br>
<br>
The former can be specified by __attribute__((regparm(N))), and the -mregparm command-line flag specifies both 2, and the default for 1.<br>
<br>
This patch adds support for 2, without changing the way 1 works. But, ISTM, both of these should be really handled similarly -- I don't much like that this patch is adding new calling convention code for 2, but leaving the handling for 1 in clang's decision about whether to use "inreg".<br>
<br>
I think, instead, that 3 new calling conventions, "x86_regparm_{1,2,3}" should be defined -- variants of the C calling convention, with a different number of args passed in registers.<br>
<br>
Then --<br>
<br>
1. Clang can emit the right cc for functions it defines/declares, rather than choosing where to place inreg.<br>
2. Which one of the calling convention to use for libcalls can be set by a subtarget feature (selected by clang based on -mregparm=N command-line option, examined by X86TargetLowering to determine what to pass to setLibcallCallingConv).<br>
<br>
<br>
<a href="https://reviews.llvm.org/D27050" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D27050</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>