On Thu, Jul 11, 2013 at 11:32 AM, John McCall <[email protected]> wrote:
> On Jul 11, 2013, at 11:18 AM, Eli Bendersky <[email protected]> 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
