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

Eli Bendersky eliben at google.com
Wed Jul 10 14:32:43 PDT 2013


On Wed, Jul 10, 2013 at 1:23 PM, John McCall <rjmccall at apple.com> wrote:

> On Jul 10, 2013, at 12:30 PM, Eli Bendersky <eliben at google.com> wrote:
>
> On Wed, Jul 10, 2013 at 11:53 AM, John McCall <rjmccall at apple.com> wrote:
>
>> On Jul 10, 2013, at 11:39 AM, Eli Bendersky <eliben at google.com> wrote:
>>
>> On Wed, Jul 10, 2013 at 11:26 AM, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Jul 10, 2013, at 11:18 AM, Eli Bendersky <eliben at google.com> wrote:
>>>
>>> On Wed, Jul 10, 2013 at 3:03 AM, John McCall <rjmccall at apple.com> wrote:
>>>
>>>> On Jun 27, 2013, at 3:57 PM, Eli Bendersky <eliben at google.com> wrote:
>>>> > Without fmath-errno, Clang currently generates calls to @llvm.pow.*
>>>> intrinsics when it sees pow*(). This may not be suitable for all targets
>>>> (for example PNaCl), so the attached patch adds a target hook that CodeGen
>>>> queries. The target can state its preference for having or not having the
>>>> intrinsic generated. Non-PNaCl behavior remains unchanged; PNaCl-specific
>>>> test added.
>>>>
>>>> Isn't a more straightforward and less invasive approach to just invoke
>>>> the compiler with -fno-builtin=pow or something along those lines?
>>>>
>>>
>>> We don't control the flags users supply to Clang though.
>>>
>>>
>>> Then handle it in the driver.
>>>
>>
>> Would that not be more intrusive, then? Or perhaps I'm misunderstanding
>> what you're proposing.
>>
>>
>> It would be isolated to target-specific logic in target-specific parts of
>> the toolchain instead of inventing a new option that's basically "do what
>> PNaCl wants" and then propagating it through the entire compiler.
>>
>
> Clang currently supports le32 as a target. So it's not an issue of a
> single "driver wrapper". We purposefully keep PNaCl as open as possible,
> and other developers and toolchain writers may use this target to generate
> PNaCl bitcode or something similar with Clang.
>
>
> 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

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130710/710d940d/attachment.html>


More information about the cfe-commits mailing list