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

John McCall rjmccall at apple.com
Wed Jul 10 14:33:58 PDT 2013


On Jul 10, 2013, at 2:32 PM, Eli Bendersky <eliben at google.com> wrote:
> 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

What functions do you want to opt out of builtin treatment?  All of them?  Just math functions?

John.

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


More information about the cfe-commits mailing list