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 Eli
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
