search for: fcos

...catch this at the DAG level. If we aren't, please let me know. OK, no problem - I was just told last time I tried to get my patch in that this was needed because the C++ frontend generated this code, I'm generating calls to fabsf() so for me this is unimportant ... > 2. Codegen fsin/fcos to fsin/fcos for X86. We cannot do this, except > under the control of something like -enable-unsafe-fp-math. These > instructions are architected to have a limited range. OK, I will add this flag. > 3. Codegen fsqrt/fsqrtf C functions to the FSQRT dag node. These > functi...

...: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050425/025894.html The patches I didn't apply are these: 1. Match (Y < 0) ? -Y : Y -> FABS in the SelectionDAGISel.cpp file. We already catch this at the DAG level. If we aren't, please let me know. 2. Codegen fsin/fcos to fsin/fcos for X86. We cannot do this, except under the control of something like -enable-unsafe-fp-math. These instructions are architected to have a limited range. 3. Codegen fsqrt/fsqrtf C functions to the FSQRT dag node. These functions can set errno, so this is not a safe tran...

Hello, I have been gone for a while, finishing work on my Master's thesis... Now that I'm back I updated LLVM to the most recent version and found that my FP_ABS SelectionDAGNode type and code generation was now conflicting with the new FABS node type. I brought the rest of my local modifications in line with the FABS implementation, so here is my patch that includes sqrt, sin and cos

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

HI developers, I want to add trigonometric instructions in my instrinfo.td files how can i directly map these instructions in .td files. Please help me Guys.For Sin, Cos, Tan and Cot Instructions. If I used llvm.sin.* as SDNode Then it is error as llvm variable is not defined SO please Help me. Thanks and Regards Varun -------------- next part -------------- An HTML attachment was scrubbed...

...e clarification on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below: UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically reference using hardware FSIN/FCOS on X86. NoExcessFPPrecision - Defaults to off (i.e. excess precision allowed), enables higher-precision implementations than specified by IEEE754. Comments reference FMA-like operations, and X87 without rounding all over the place. LessPreciseFPMADOption - Defaults to off, enables "less pre...

Hello, I'm currently adding the floating point math instructions (fabs, fsin, fcos ...) to the x86 instruction set. I'm a bit unsure how to make the back end actually generate these instructions, though. My current plan is to add llvm intrinsics for these instructions but I've noticed that llvm already handles C math library functions to some extent. It feels a bit st...

...e clarification on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below: UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically reference using hardware FSIN/FCOS on X86. NoExcessFPPrecision - Defaults to off (i.e. excess precision allowed), enables higher-precision implementations than specified by IEEE754. Comments reference FMA-like operations, and X87 without rounding all over the place. LessPreciseFPMADOption - Defaults to off, enables "less pre...

New patch here -- it's not been tested yet because we're having some problems with the application (I can't create new VM programs at the moment), but it compiles OK ;-) Please look over it and see if there are some more changes you'd like me to make before you can commit it... m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed...

On Tue, 4 Jan 2005, Morten Ofstad wrote: > I'm currently adding the floating point math instructions (fabs, fsin, fcos > ...) to the x86 instruction set. Cool! > I'm a bit unsure how to make the back end actually generate these > instructions, though. My current plan is to add llvm intrinsics for > these instructions but I've noticed that llvm already handles C math > library functions...

...semantics for the various FP precision-related > TargetOptions. I've summarized the three relevant ones below: > > > UnsafeFPMath - Defaults to off, enables "less precise" results than > permitted by IEEE754. Comments specifically reference using hardware > FSIN/FCOS on X86. > > > NoExcessFPPrecision - Defaults to off (i.e. excess precision allowed), > enables higher-precision implementations than specified by IEEE754. > Comments reference FMA-like operations, and X87 without rounding all > over the place. > > > LessPreciseFPMADO...

...+ case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperati...

...ERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + case ISD::SIGN_EXTEND: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperati...

...rg0, Arg1); > + //negate sign > + OVF = DAG.getNode(ISD::SUB, DL, VT, DAG.getConstant(0, VT), OVF); > + SDValue Res = DAG.getNode(ISD::SUB, DL, VT, Arg0, Arg1); > + > + return DAG.getNode(ISD::MERGE_VALUES, DL, DAG.getVTList(VT, VT), Res, OVF); > + } > case ISD::FCOS: > case ISD::FSIN: return LowerTrig(Op, DAG); > case ISD::SELECT_CC: return LowerSELECT_CC(Op, DAG); > diff --git a/test/CodeGen/R600/add.ll b/test/CodeGen/R600/add.ll > index 8cf43d1..fddb951 100644 > --- a/test/CodeGen/R600/add.ll > +++ b/test/CodeGen/R600/add.ll > @@ -...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...ERO_EXTEND: + case ISD::ANY_EXTEND: + case ISD::TRUNCATE: + case ISD::SIGN_EXTEND: + case ISD::SINT_TO_FP: + case ISD::UINT_TO_FP: + case ISD::FP_TO_SINT: + case ISD::FP_TO_UINT: + case ISD::FNEG: + case ISD::FABS: + case ISD::FSQRT: + case ISD::FSIN: + case ISD::FCOS: + case ISD::FPOWI: + case ISD::FPOW: + case ISD::FLOG: + case ISD::FLOG2: + case ISD::FLOG10: + case ISD::FEXP: + case ISD::FEXP2: + case ISD::FCEIL: + case ISD::FTRUNC: + case ISD::FRINT: + case ISD::FNEARBYINT: + case ISD::FFLOOR: + switch (TLI.getOperati...