[PATCH] CodeGen target hook for emitting intrinsic or libcall for pow*
eliben at google.com
Thu Jul 11 13:58:51 PDT 2013
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
>>> 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
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits