On Jul 10, 2013, at 2:32 PM, Eli Bendersky <[email protected]> wrote: > On Wed, Jul 10, 2013 at 1:23 PM, John McCall <[email protected]> wrote: > On Jul 10, 2013, at 12:30 PM, Eli Bendersky <[email protected]> wrote: >> On Wed, Jul 10, 2013 at 11:53 AM, John McCall <[email protected]> wrote: >> On Jul 10, 2013, at 11:39 AM, Eli Bendersky <[email protected]> wrote: >>> On Wed, Jul 10, 2013 at 11:26 AM, John McCall <[email protected]> wrote: >>> On Jul 10, 2013, at 11:18 AM, Eli Bendersky <[email protected]> wrote: >>>> On Wed, Jul 10, 2013 at 3:03 AM, John McCall <[email protected]> wrote: >>>> On Jun 27, 2013, at 3:57 PM, Eli Bendersky <[email protected]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
