search for: fp_round_inreg

Displaying 10 results from an estimated 10 matches for "fp_round_inreg".

2018 Feb 13
1
Test for ISD::FP_ROUND_INREG?
Do we have a test that exercises ISD::FP_ROUND_INREG in SelectionDAGLegalize::ExpandNode()? I ask because I'm working on code that reuses that block in the switch and I'm trying to write a test. But I'm having trouble and would like to see what a working test for the existing code looks like. A quick grep of the tree doesn't show any...
2008 Aug 22
3
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
...============================================ > --- 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 > setOperationAction(ISD::SREM, MVT::i32, Expand); > setOperationA...
2008 Aug 19
2
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
...p =================================================================== --- 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 setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand);...
2008 Aug 21
2
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
...p =================================================================== --- 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 setOperationAction(ISD::SREM, MVT::i32, Expand); setOperationAction(ISD::UREM, MVT::i32, Expand);...
2008 Aug 22
0
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
...========================== >> --- 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 >> setOperationAction(ISD::SREM, MVT::i32, Expand); &...
2008 Aug 21
0
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
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,
2008 Aug 21
0
[LLVMdev] Implementing llvm.memory.barrier on PowerPC
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
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...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, Result); -...