<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 6:57 AM, Joerg Sonnenberger via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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"><span class="">On Wed, Jan 27, 2016 at 05:53:33PM -0800, Matt Arsenault via llvm-dev wrote:<br>
> I would like to propose that when available, if a C builtin function has an<br>
> equivalent llvm intrinsic, that the intrinsic be the preferred form. The<br>
> equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls<br>
> should replace calls with the intrinsic.<br>
<br>
</span>As long as you make sure that it deals properly with renames used on the<br>
prototypes... E.g. a call to "double sin(double)" can easily be forced<br>
to use "my_better_sin_function" on the C level. One huge problem with<br>
the "everything as __builtin mess" GCC introduced was to effectively<br>
remove any sane way to model such behavior.<br></blockquote><div><br></div><div>I'm not familiar with what happened to GCC, but I like this proposal because I know there are optimization holes due to not matching both the intrinsic and the libcall. Double --> float shrinking and fmax/fmin are cases I noticed recently. Pulling the intrinsic optimizations out of SimplifyLibCalls should also make it easier to refactor the library function prototype checking. I made a few changes here after <a href="https://llvm.org/bugs/show_bug.cgi?id=26211" class="" target="_blank" rel="noreferrer">https://llvm.org/bugs/show_bug.cgi?id=26211</a> , but it's still a mess.<br><br></div><div>cc'ing Davide as he might have some ideas about cleaning up SimplifyLibCalls too.<br></div><div><br><br></div><div> </div></div></div></div>