<div dir="ltr"><div class="gmail_extra">First off, thanks for the awesome description of the change. =]</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 1:49 PM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com" target="_blank">evan.cheng@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":21v" class="a3s" style="overflow:hidden">I can think of 3 options to fix this.<br>
<br>
1. Make "C" calling convention just work since the target should know what CC<br>
   is being used.<br>
<br>
   This doesn't work because each function can use different CC with the "pcs"<br>
   attribute.<br>
<br>
2. Have Clang add the right CC keyword on the calls to LLVM builtin.<br>
<br>
   This will work but it doesn't match the LLVM IR specification which states<br>
   these are "Standard C Library Intrinsics".<br>
<br>
3. Fix simplify libcall so the resulting calls to the C routines will have the<br>
   proper CC keyword. e.g.<br>
   %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1<br>
<br>
   This works and is the solution I implemented here.<br>
<br>
Both solutions #2 and #3 would work. After carefully considering the pros and<br>
cons, I decided to implement #3 for the following reasons.<br>
<br>
1. It doesn't change the "spec" of the intrinsics.<br>
2. It's a self-contained fix.<br>
<br>
There are a couple of potential downsides.<br>
1. There could be other places in the optimizer that is broken in the same way<br>
   that's not addressed by this.<br>
2. There could be other calling conventions that need to be propagated by<br>
   simplify-libcall that's not handled.<br>
<br>
But for now, this is the fix that I'm most comfortable with.</div></blockquote></div><br>Agreed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Here is a suggested option #4 which only makes sense in the long term, but might be more palatable than #1 in the long term.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We could require that the target provide a libcall description for all library functions which have an IR intrinsic form. These could look not entirely dissimilar from the existing hooks for a target to inform IR passes about available library calls on a specific platform, and could include such details as what calling conventions should be used. Then this code (and any other optimizer code) could use these target-provided libcall descriptions to write correct calls into the library. This would also give us a nice way of modeling freestanding implementations where there *is* no libc function of note.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Other than this, I like option #2 the best. Clang already knows how to call the libc function correctly; having it encode this in the call to the intrinsic seems natural and easy. It is a spec change, but it seems a good spec change to me at least.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Maybe file a PR to revisit this and go after one of these solutions?</div></div>