search for: nonansfpmath

..."); RESET_OPTION(NoFramePointerElimNonLeaf, "no-frame-pointer-elim-non-leaf"); RESET_OPTION(LessPreciseFPMADOption, "less-precise-fpmad"); RESET_OPTION(UnsafeFPMath, "unsafe-fp-math"); RESET_OPTION(NoInfsFPMath, "no-infs-fp-math"); RESET_OPTION(NoNaNsFPMath, "no-nans-fp-math"); RESET_OPTION(UseSoftFloat, "use-soft-float"); RESET_OPTION(DisableTailCalls, "disable-tail-calls"); I cannot find the code or mechanism to turn off: NoFramePointerElim No code generator has these specialized, so this is happening for all targ...

...deModel::JITDefault); builder.setMCPU(llvm::sys::getHostCPUName()); TargetOptions targetOptions; targetOptions.NoFramePointerElim = true; targetOptions.LessPreciseFPMADOption = true; targetOptions.UnsafeFPMath = true; targetOptions.NoInfsFPMath = true; targetOptions.NoNaNsFPMath = true; targetOptions.GuaranteedTailCallOpt = true; builder.setTargetOptions(targetOptions); TargetMachine* tm = builder.selectTarget(); fJIT = builder.create(tm); if (!fJIT) { return false; } …. Any idea? Thanks. Stéphane Letz

...der.setMCPU(llvm::sys::getHostCPUName()); > > TargetOptions targetOptions; > targetOptions.NoFramePointerElim = true; > targetOptions.LessPreciseFPMADOption = true; > targetOptions.UnsafeFPMath = true; > targetOptions.NoInfsFPMath = true; > targetOptions.NoNaNsFPMath = true; > targetOptions.GuaranteedTailCallOpt = true; > > builder.setTargetOptions(targetOptions); > > TargetMachine* tm = builder.selectTarget(); > > fJIT = builder.create(tm); > if (!fJIT) { > return false; > } > …. > > Any...

...17758 in particular would be to revert the Clang change, introduce a new intrinsic for sqrt that does match the libm semantics, and have vectorization use that when available. Another alternative is to revert the Clang change and make autovectorization of libm sqrt -> llvm.sqrt dependent on the NoNaNsFPMath TargetOptions flag (this requires directly exposing parts of TargetOptions to the IR level). I believe that both of these alternatives also require fixing the inliner to deal properly with fast-math attributes during LTO (unless I can just ignore this for now). This was the objection raised to the...

...I haven't applied your > patch to see what the IR changes look like here. > > With the patches applied, the attributes clang embeds in the IR look like this: $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 -menable-no-nans attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "stack-protector-...

...getHostCPUName()); >> >> TargetOptions targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInfsFPMath = true; >> targetOptions.NoNaNsFPMath = true; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTargetOptions(targetOptions); >> >> TargetMachine* tm = builder.selectTarget(); >> >> fJIT = builder.create(tm); >> if (!fJIT) { >> return false; &gt...

...particular would be to revert the Clang change, introduce a new intrinsic for sqrt that does match the libm semantics, and have vectorization use that when available. > > Another alternative is to revert the Clang change and make autovectorization of libm sqrt -> llvm.sqrt dependent on the NoNaNsFPMath TargetOptions flag (this requires directly exposing parts of TargetOptions to the IR level). > > I believe that both of these alternatives also require fixing the inliner to deal properly with fast-math attributes during LTO (unless I can just ignore this for now). This was the objection rais...

...to the bitcode too. Pre-existing attributes in the bitcode are overwritten by the options in the command line. 3. The backend passes and subtarget classes call getFunctionAttribute to read the attributes stored to the bitcode in step 2. Function::hasFnAttribute can be called directly (for example, NoNaNsFPMath in the patch), if the default value is known to be "false". I also made the following changes in the patch: 1. In the constructor of MachineFunction, call the version of getSubtargetImpl that takes a Function parameter, so that it gets the Subtarget specific to the Function being compil...

...pplied your patch to see what the IR changes look like here. > > > With the patches applied, the attributes clang embeds in the IR look like this: > > $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 -menable-no-nans > attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "stack-protector-...

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this

...what the IR changes look like here. >> >> >> With the patches applied, the attributes clang embeds in the IR look like this: >> >> $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 -menable-no-nans >> attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "stack-protector-...

...patches applied, the attributes clang embeds in the IR look >>>> like this: >>>> >>>> $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 >>>> -menable-no-nans >>>> >>>> attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" >>>> "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" >>>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" >>>> "no-infs-fp-...

...the IR look >>>>>> like this: >>>>>> >>>>>> $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 >>>>>> -menable-no-nans >>>>>> >>>>>> attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" >>>>>> "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" >>>>>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" >>>>&g...

...getHostCPUName()); >> >> TargetOptions targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInfsFPMath = true; >> targetOptions.NoNaNsFPMath = true; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTargetOptions(targetOptions); >> >> TargetMachine* tm = builder.selectTarget(); >> >> fJIT = builder.create(tm); >> if (!fJIT) { >> return false; &gt...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...4 --- a/include/llvm/Target/TargetOptions.h +++ b/include/llvm/Target/TargetOptions.h @@ -62,7 +62,7 @@ namespace llvm { TargetOptions() : PrintMachineCode(false), NoFramePointerElim(false), LessPreciseFPMADOption(false), UnsafeFPMath(false), - NoInfsFPMath(false), NoNaNsFPMath(false), + NoInfsFPMath(false), NoNaNsFPMath(false), HonorFPExceptions(false), HonorSignDependentRoundingFPMathOption(false), UseSoftFloat(false), NoZerosInBSS(false), JITEmitDebugInfo(false), JITEmitDebugInfoToDisk(false), GuaranteedTailCallOpt(false), @@ -...

...ke this: >>>>>>>> >>>>>>>> $ clang -cc1 ... -mllvm -arm-long-calls -mllvm -arm-reserve-r9 >>>>>>>> -menable-no-nans >>>>>>>> >>>>>>>> attributes #0 = { nounwind readonly ssp "NoNaNsFPMath" >>>>>>>> "arm-long-calls"="1" "arm-reserve-r9"="1" "less-precise-fpmad"="false" >>>>>>>> "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" &g...

...as storing all FMF in > metadata) was discussed here: > https://llvm.org/bugs/show_bug.cgi?id=13118 > 3. The backend needs a thread of its own. We have at least these > mechanisms to handle FMA codegen: > a. TargetOptions for LessPreciseFPMADOption, UnsafeFPMath, > NoInfsFPMath, NoNaNsFPMath, AllowFPOpFusion (Fast, Standard, Strict) > b. SDNodeFlags for UnsafeAlgebra, NoNaNs, NoInfs, NoSignedZeros (but > nothing for FMA since IR FMF has nothing for FMA) > c. SelectionDAGTargetInfo::generateFMAsInMachineCombiner() > d. TargetLoweringBase::isFMAFasterThanFMulAndFAdd() &gt...

Sent from my Verizon Wireless 4G LTE DROID On Nov 17, 2016 5:53 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Nov 17, 2016, at 4:33 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Warren

...troduce a new intrinsic for > > sqrt that does match the libm semantics, and have vectorization > > use that when available. > > > > Another alternative is to revert the Clang change and make > > autovectorization of libm sqrt -> llvm.sqrt dependent on the > > NoNaNsFPMath TargetOptions flag (this requires directly exposing > > parts of TargetOptions to the IR level). > > > > I believe that both of these alternatives also require fixing the > > inliner to deal properly with fast-math attributes during LTO > > (unless I can just ignore th...