search for: fp_round

Hi Guys, I and trying to covert a float to a f16. calling DAG.getNode(ISD::FP_ROUND, DL, Op->getValueType(0), FloatNode); will get the error message:"Invalid method to make FP_ROUND node" what is the "right" way to make this work? best Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piper...

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackCon...

Hi Bruno, > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which i...

On Mon, 7 Jul 2008, Bruno Cardoso Lopes wrote: > I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that > only supports single > float point operations. The problem is that f32 is considered legal on this > target but f64 doesn't and the only way I can codegen this instruction is using > setConvertAction(MVT::f64, MVT::f32, Expand), which i...

I'd like to start a discussion about how clang supports _Float16 for target architectures that don't have direct support for 16-bit floating point arithmetic. The current clang language extensions documentation says, "If half-precision instructions are unavailable, values will be promoted to single-precision, similar to the semantics of __fp16 except that the results will be stored

...leaner. - As a consequence, the isel dags are in a more 'normal form'. I.e. it relies less on funny nodes FP_TO_FP16 and FP16_TO_FP, which are funny because they perform float up/down converts and produce i32 values by moving from/to integer and float registers. Instead, FP_EXTEND and FP_ROUND nodes will be introduced, so this is more a clean up rather than e.g. addressing a correctness issue. Unfortunatly I found that I can't completely get rid of nodes FP16_TO_FP, see 'Custom Lowering' below. - When these FP_EXTEND and FP_ROUND are introduced by the legalizer, and w...

...td" > Index: lib/Target/PowerPC/PPCISelLowering.cpp > =================================================================== > --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) > +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) > @@ -78,9 +78,6 @@ > // from FP_ROUND: that rounds to nearest, this rounds to zero. > setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); > > - // PowerPC has no intrinsics for these particular operations > - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); > - > // PowerPC has no SREM/UR...

...include "PPCInstr64Bit.td" Index: lib/Target/PowerPC/PPCISelLowering.cpp =================================================================== --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) @@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperatio...

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference

...include "PPCInstr64Bit.td" Index: lib/Target/PowerPC/PPCISelLowering.cpp =================================================================== --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) @@ -78,9 +78,6 @@ // from FP_ROUND: that rounds to nearest, this rounds to zero. setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); - // PowerPC has no intrinsics for these particular operations - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); - // PowerPC has no SREM/UREM instructions setOperatio...

Hi, What is the rounding mode for the fptrunc instruction? Round to zero? Round to nearest? Or undefined? Regards, Jon

...: lib/Target/PowerPC/PPCISelLowering.cpp >> =================================================================== >> --- lib/Target/PowerPC/PPCISelLowering.cpp (revision 54985) >> +++ lib/Target/PowerPC/PPCISelLowering.cpp (working copy) >> @@ -78,9 +78,6 @@ >> // from FP_ROUND: that rounds to nearest, this rounds to zero. >> setOperationAction(ISD::FP_ROUND_INREG, MVT::ppcf128, Custom); >> >> - // PowerPC has no intrinsics for these particular operations >> - setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand); >> - >> // Po...

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

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

...k; - case Expand: { - MVT VT = Op.getValueType(); - MVT OVT = Node->getOperand(0).getValueType(); - // Convert ppcf128 to i32 - if (OVT == MVT::ppcf128 && VT == MVT::i32) { - if (Node->getOpcode() == ISD::FP_TO_SINT) { - Result = DAG.getNode(ISD::FP_ROUND_INREG, dl, MVT::ppcf128, - Node->getOperand(0), DAG.getValueType(MVT::f64)); - Result = DAG.getNode(ISD::FP_ROUND, dl, MVT::f64, Result, - DAG.getIntPtrConstant(1)); - Result = DAG.getNode(ISD::FP_TO_SINT, dl, VT, Resu...

...legal for the storage-only case, but which I am ready to abandon: - Define the HPR register class, - Use this and make f16 legal also in the storage-only case, -- This works for the storage-only case, because data processing instruction that have f16 operands will get promoted and fp_extend and fp_round nodes will be introduced. Then I manually patch up the f16 loads and stores and a few other corner cases by manually lowering them. This however is a fragile approach, which was rightfully commented by Oli, also after being inspired by a recent discussion about some backends doing their...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...legal for the storage-only case, but which I am ready to abandon: - Define the HPR register class, - Use this and make f16 legal also in the storage-only case, -- This works for the storage-only case, because data processing instruction that have f16 operands will get promoted and fp_extend and fp_round nodes will be introduced. Then I manually patch up the f16 loads and stores and a few other corner cases by manually lowering them. This however is a fragile approach, which was rightfully commented by Oli, also after being inspired by a recent discussion about some backends doing their...