[PATCH] CodeGen target hook for emitting intrinsic or libcall for pow*

John McCall rjmccall at apple.com
Thu Jul 11 11:32:39 PDT 2013

On Jul 11, 2013, at 11:18 AM, Eli Bendersky <eliben at google.com> wrote:
> 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.
>>> Oh, it turns out Clang does not currently support -fno-builtin-<FUNC> at all: 
>>> http://llvm.org/bugs/show_bug.cgi?id=4941
>> What functions do you want to opt out of builtin treatment?  All of them?  Just math functions?
>> 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?
> 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>.
> 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".


> 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?

Looking at the header string is fine for now.

> 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?)

In the ToolChain, I think.

> As for:
> > just add frontend support for -fno-builtin-<FUNC>.
> 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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130711/4d681e45/attachment.html>

More information about the cfe-commits mailing list