search for: fpow

...ions of up to 16 elements as the 1.0 spec requires. Is this something that I could Merge back into the tree or is another approach required? Some of the thoughts we were having as not to clutter the llvm namespace was to add a math namespace and the intrinsic would go there instead. i.e. llvm.math.fpow, llvm.math.fpowi, llvm.math.fpowr, etc... Any ideas? Thanks, Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Monday, April 13, 2009 6:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Math Lib...

On Apr 8, 2009, at 12:43 AM, Duncan Sands wrote: > Hi Micah, > >> There seems to be some math library functions that are already built >> into llvm as intrinsic(pow, exp, etc...) but there are lots that >> are not >> built in yet. Is there currently work going on that is implementing >> these? I do not want to duplicate work so I want to see what is out

The X86 back-end just calls into libm: // Always use a library call for pow. setOperationAction(ISD::FPOW , MVT::f32 , Expand); setOperationAction(ISD::FPOW , MVT::f64 , Expand); setOperationAction(ISD::FPOW , MVT::f80 , Expand); The issue is really that there is no standard math library for PTX. I agree that this is a pain for most users, but I don't t...

...d which ones will make him to crash. So, there is need to modify something in the backend, anyways. - D. 2013/2/17 Justin Holewinski <justin.holewinski at gmail.com> > The X86 back-end just calls into libm: > > // Always use a library call for pow. > setOperationAction(ISD::FPOW , MVT::f32 , Expand); > setOperationAction(ISD::FPOW , MVT::f64 , Expand); > setOperationAction(ISD::FPOW , MVT::f80 , Expand); > > > The issue is really that there is no standard math library for PTX. I > agree that this is a pain for m...

...s need to > modify something in the backend, anyways. > > > - D. > > 2013/2/17 Justin Holewinski <justin.holewinski at gmail.com> > >> The X86 back-end just calls into libm: >> >> // Always use a library call for pow. >> setOperationAction(ISD::FPOW , MVT::f32 , Expand); >> setOperationAction(ISD::FPOW , MVT::f64 , Expand); >> setOperationAction(ISD::FPOW , MVT::f80 , Expand); >> >> >> The issue is really that there is no standard math library for PTX. I >> agree t...

...ackend, anyways. >> >> >> - D. >> >> 2013/2/17 Justin Holewinski <justin.holewinski at gmail.com> >> >>> The X86 back-end just calls into libm: >>> >>> // Always use a library call for pow. >>> setOperationAction(ISD::FPOW , MVT::f32 , Expand); >>> setOperationAction(ISD::FPOW , MVT::f64 , Expand); >>> setOperationAction(ISD::FPOW , MVT::f80 , Expand); >>> >>> >>> The issue is really that there is no standard math library for PTX....

Hi Justin, I don't understand, why, for instance, X86 backend handles pow automatically, and NVPTX should be a PITA requiring user to bring his own pow implementation. Even at a very general level, this limits the interest of users to LLVM NVPTX backend. Could you please elaborate on the rationale behind your point? Why the accuracy modes I suggested are not sufficient, in your opinion? - D.

There's at least one other LLVM user which would find these useful, and probably more, so it may be appropriate to merge this into the main tree. I'm interested to hear if anyone else has an opinion here. An llvm.math namespace seems like a good idea. Instead of using "fpow" though, I'd prefer to just use names like "pow". For consistency, the ISD namespace operators could be renamed to MATH_POW and similar. The text in LangRef.html that describes the semantics of llvm.pow needs improvement. Here's an attempt at an improved description of error...

...+ 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.getOperationAction(I->getOpc...

...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.getOperationAction(I->getOpc...

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

...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.getOperationAction(I->getOpc...