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

[Eli Bendersky]

On Thu, Jul 11, 2013 at 11:32 AM, John McCall <rjmccall at apple.com> wrote:

> 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".
>
>
> Right.
>
> 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.
>
>
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.

Eli




> 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.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130711/67136847/attachment.html>