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