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. > There's no new option added and no additional plumbing done in this change. > Target hooks are used in a number of places in Clang codegen already to > customize parts of the process. A new hook was added for this specific > purpose, and the only PNaCl-specific part of the code is in > PNaClTargetCodeGenInfo. This is not unlike already existing target hooks for > architectures, OSes, etc. Those hooks are used for mandatory ABI things, though, not to adjust our interpretation of builtin functions. The builtin model is already complicated enough. John.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
