<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 11:32 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@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 style="word-wrap:break-word"><div><div class="im"><div>On Jul 11, 2013, at 11:18 AM, Eli Bendersky <<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>I'm not asking you to wrap the driver.  I'm asking you to change clang's driver logic when targeting *-*-nacl to use the existing logic to suppress builtin treatment of functions.<br>

<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Oh, it turns out Clang does not currently support -fno-builtin-<FUNC> at all: </div>

<div><a href="http://llvm.org/bugs/show_bug.cgi?id=4941" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=4941</a></div>

</div></div></div></blockquote><br></div><div>What functions do you want to opt out of builtin treatment?  All of them?  Just math functions?</div></div></blockquote><div><br></div><div>For starters, math functions. There aren't many libc math functions handled there, BTW. When I was working on the original patch I dug through history - a couple were added (pow and sqrt) I think, and sqrt was then backed off due to some problems. Even with pow there are other constrains such as errno (the builtin is not generated when we want errno, naturally, even without -fno-builtins). Perhaps I can make the target hook more generic - controlling all math libraries (the BIfoo ones, not BI__builtin_foo) instead of just pow?</div>


</div></div></div></blockquote><br></div></div><div>I really don't want this to be an IR-gen target hook, but adding a cc1-level ability to disable builtin treatment for math functions makes sense to me, or you can just add frontend support for -fno-builtin-<FUNC>.</div>

</div></blockquote><div><br></div><div>I looked some more into this. There currently no hooks to say something like "disable builtin treatment for math functions" because of the way builtins are populated and identified. If I understand you correctly, you want this decision to be made before IR gen; meaning that you want something that says "this name is not a builtin at all, for some special conditions".</div>
</div></div></div></blockquote><div><br></div></div>Right.</div><div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>One way to implement this is mark the math builtins somehow in Builtins.def and then have a new LangOpts option to tweak that. Then, when builtins are read and populated in Builtin::Context::InitializeBuiltins, math builtins can be skipped. Recognizing math builtins can be done by looking at the header specified for them in Builtins.def - would this work, or do we need some special attribute?</div>
</div></div></div></blockquote><div><br></div></div><div>Looking at the header string is fine for now.</div><div class="im"><br></div></div></div></blockquote><div><br></div><div>OK, I sent a patch for this first part (adding -fno-math-builtin to the frontend). Once we hash it out, I can send a target-dependent invocation in the driver as a separate patch.</div>
<div><br></div><div>Eli</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im">
<blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>Now, once that's in place a new cc1-level flag can be added and in the driver we can always force this flag for PNaCl (is there a place/precedent for target-specific forcing of cc1 flags in the driver?)</div></div>
</div></div></blockquote><div><br></div></div>In the ToolChain, I think.</div><div class="im"><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>As for:</div><div><br></div><div>> just add frontend support for -fno-builtin-<FUNC>.</div><div><br></div><div>This looks quite challenging. I'm not sure the LangOptions infrastructure supports such options (and the command-line parsing library for the gcc-compatible way) so there's a whole bunch of infrastructure that needs to be upgraded. Maybe I'm missing something basic, though.</div>
</div></div></div></blockquote><div><br></div></div></div>LangOptions already has a couple fields that don't fit cleanly into LangOptions.def.  It just means you need to do (e.g.) serialization code manually.<span class="HOEnZb"><font color="#888888"><div>
<br></div><div>John.</div></font></span></div>
</blockquote></div><br></div></div>