search for: uint_to_fp

Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) ... case ISD::SINT_TO_FP: case ISD::UINT_TO_FP: case ISD::EXTRACT_VECTOR_ELT: Action = TLI.getOperationAction(Node->getOpcode(), Node->getOperand(0).getValueType()); This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. i.e. it should be: case...

...Thanks for explaining that. Could you put this in a comment? >> >> >> >> Actually, I went ahead and tried writing the patch to remove type >> >> legalization from LegalizeDAG; I actually ran into another issue, >> >> which is the legalization of i32 UINT_TO_FP. We want to legalize it >> >> into an i64 UINT_TO_FP, but that requires type legalization. I'm not >> >> quite sure what to do about that; if I can't come up with a better >> >> solution, I'll force the x86 backend to custom-lower that case. >&gt...

Hi As 32-bit mode doesn't have 64-bit GPR, the sequence converting v2i32 to v2f32 is quite inefficient in 32-bit mode. This patch adds the custom lowering in 32-bit mode. In addition, it teaches DAG combine to transform (build_vec (Xint2fp x) (Xint2fp y) ..) to (Xint2fp (build_vec x y)) to reduce the strength on FP conversion unit. Thanks for your review Yours - Michael -------------- next

...lmow, Micah wrote: > Is there anywhere in the codebase that actually uses the ConvertAction to determine how conversion functions are lowered? I don't see any. > > In SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op) > > ... > case ISD::SINT_TO_FP: > case ISD::UINT_TO_FP: > case ISD::EXTRACT_VECTOR_ELT: > Action = TLI.getOperationAction(Node->getOpcode(), > Node->getOperand(0).getValueType()); > > This seems incorrect as SINT_TO_FP should be querying the convert action, and not the Operation action. &...

...nstants in TableGen definitions? Let's say I have the following pattern: def : Pat<(i1 (trunc RegI16:$a)), (SETPGTu16ri RegI16:$a, 0)>; Note the zero constant in the result. Is there a way to represent floating-point literals in the same way? Something like... def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a, (f32 0.0))>; This unfortunately does not work. Right now I'm getting around this by using alternate instructions to first convert from an integer immediate, something like: def : Pat<(i1 (uint_to_fp RegF32:$a)), (SETPGTf32ri RegF32:$a, (MO...

...re potential alternatives, > like making LegalizeDAG call back into type legalization, but it gets > messy.) > > Actually, I went ahead and tried writing the patch to remove type > legalization from LegalizeDAG; I actually ran into another issue, > which is the legalization of i32 UINT_TO_FP.  We want to legalize it > into an i64 UINT_TO_FP, but that requires type legalization.  I'm not > quite sure what to do about that; if I can't come up with a better > solution, I'll force the x86 backend to custom-lower that case. Attached is a more complete version, includin...

...type legalization. (There are potential alternatives, like making LegalizeDAG call back into type legalization, but it gets messy.) Actually, I went ahead and tried writing the patch to remove type legalization from LegalizeDAG; I actually ran into another issue, which is the legalization of i32 UINT_TO_FP. We want to legalize it into an i64 UINT_TO_FP, but that requires type legalization. I'm not quite sure what to do about that; if I can't come up with a better solution, I'll force the x86 backend to custom-lower that case. -Eli

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

...ND: + case ISD::OR: + case ISD::XOR: + case ISD::SHL: + case ISD::SRA: + case ISD::SRL: + case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + 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: + cas...

...case ISD::ROTL: + case ISD::ROTR: + case ISD::CTTZ: + case ISD::CTLZ: + case ISD::CTPOP: + case ISD::SELECT: + case ISD::SELECT_CC: + case ISD::ZERO_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: + cas...

...o have the same type as this > + // SELECT_CC node. > + > + if (CompareVT != VT) { > + ISD::NodeType ConversionOp = ISD::DELETED_NODE; > + if (VT == MVT::f32 && CompareVT == MVT::i32) { > + if (isUnsignedIntSetCC(CCOpcode)) { > + ConversionOp = ISD::UINT_TO_FP; > + } else { > + ConversionOp = ISD::SINT_TO_FP; > + } > + } else if (VT == MVT::i32 && CompareVT == MVT::f32) { > + ConversionOp = ISD::FP_TO_SINT; > + } else { > + // I don't think there will be any other type pairings. > +...