search for: sint_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....

...ar 19, 2010, at 12:23 PM, Villmow, 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, an...

Can someone explain why TableGen can't figure this out? VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! The pattern as written looks like this: [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))] I'm trying to unify AVX/SSE...

I just ran into this today with x86-64: Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> As far as I can tell, DAGCombiner comes along and sees an sint_to_fp of the constant 1 and hapilly folds it into a ConstantFP<1>. ISel then blows up because there's no pattern for it. Does this look familiar to anyone? I don't see any relevant bugs in the database. -Dave

...ined? The bitconvert in the tablegen output is marked isInt, which means it's the node that didn't get inferred. Dan On Jun 4, 2009, at 1:06 PM, David Greene wrote: > Can someone explain why TableGen can't figure this out? > > VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 > (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) > llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! > > The pattern as written looks like this: > > [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))] > &...

On Sep 24, 2008, at 5:11 PM, David Greene wrote: > I just ran into this today with x86-64: > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > of the > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > blows up > because there's no pattern for it. > > Does this look familiar to anyone? I don't see any relevant bugs in > the > database. Do you have a testcase? It sounds like...

...ee how this relates to regex's, and really don't want to suck > in an external regex library. Can you give an example of how this > would help? Sure: [Top-level specification] defm CVTSI2SS : sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm< 0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">; [Meanwhile, down in the guts...] class fp_cvt_scalar_VXSnrr< // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr bits<8> opc, string OpcodeStr, SDNode OpNode, string DstType, string SrcType, int CustomPatter...

I have IR at https://ghostbin.com/paste/daxv5 <https://ghostbin.com/paste/daxv5> which is meant to exit 1, but it is always exiting 0. I'm using it as a template for checking if two functions @test1 and @test2 are equivalent by checking against the exhaustive possible i16 values. For this particular example it should be enough to know that for certain i16, @test1 and @test2 are *not*

...TO_FP , MVT::i64 , Custom); - - // We have faster algorithm for ui32->single only. - setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Custom); } else { - setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Promote); + // Otherwise, let the legalizer turn this into an SINT_TO_FP + setOperationAction(ISD::UINT_TO_FP , MVT::i64 , Expand); } + if (!UseSoftFloat) { + // We have an algorithm for SSE2, and we turn this into a 64-bit + // FILD on other platforms. + setOperationAction(ISD::UINT_TO_FP , MVT::i32 , Custom); + } } // Promo...

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

...ptember 2008 19:12, Chris Lattner wrote: > On Sep 24, 2008, at 5:11 PM, David Greene wrote: > > I just ran into this today with x86-64: > > > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > > of the > > constant 1 and hapilly folds it into a ConstantFP<1>. ISel then > > blows up > > because there's no pattern for it. > > > > Does this look familiar to anyone? I don't see any relevant bugs in > > the > > database. > &...

On Fri, Jun 5, 2009 at 8:51 AM, David Greene<dag at cray.com> wrote: > def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins f128mem: > $src), >                         "cvtsd2si\t{$src, $dst|$dst, $src}", >                         [(set GR32:$dst, (int_x86_sse2_cvtsd2si >                                           (load addr:$src)))]>; > > Er,

...uctions. See the definition of CVTSD2SIrm. In some cases, yes. But not all of the X86 instructions are accessible through LLVM IR. And sometimes we like the ability to have our frontend lower to intrinsics so we know EXACTLY what code will come out the other end. And see my previous post about sint_to_fp with a memory operand not working in TableGen ("TableGen Type Inference"). I'll be debugging that next week, probably. -Dave

On Friday 05 June 2009 17:41, Dan Gohman wrote: > How is bc_memopv4i32 defined? The bitconvert in the tablegen > output is marked isInt, which means it's the node that didn't get > inferred. def bc_memopv4i32 : PatFrag<(ops node:$ptr), (bitconvert (memopv4i32 node:$ptr))>; -Dave

...[(set DstRC:$dst, (OpNode SrcRC:$src))]>; def rm : SI<opc, MRMSrcMem, (outs DstRC:$dst), (ins x86memop:$src), asm, [(set DstRC:$dst, (OpNode (ld_frag addr:$src)))]>; } let isAsmParserOnly = 0 in { defm SInt_VCVTSI2SD : sse12_vcvt_avx_s<0x2A, GR32, FR64, sint_to_fp, i32mem, loadi32, "cvtsi2sd\t{$src, $dst, $dst|$dst, $dst, $src}">, XD, VEX; ... } let isAsmParserOnly = 1 in { defm VCVTSI2SD : sse12_vcvt_avx<0x2A, GR32, FR64, i32mem, "cvtsi2sd">, XD,...

...9;t want to >> suck >> in an external regex library. Can you give an example of how this >> would help? > > Sure: > > [Top-level specification] > defm CVTSI2SS : > sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm< > 0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">; > > [Meanwhile, down in the guts...] > > class fp_cvt_scalar_VXSnrr< > // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr > bits<8> opc, > string OpcodeStr, > SDNode OpNode, > string DstType,...

On May 20, 2009, at 9:14 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 5:26 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> 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

On Jun 9, 2009, at 12:39 PM, David Greene wrote: > On Tuesday 09 June 2009 14:34, Dan Gohman wrote: >> Can you describe what problem you're trying to solve here? Does it >> really need Regular Expressions? > > Yes. I want TableGen to be able to infer lots of stuff > programmatically. > This helps tremendously when specifying things like, oh, AVX. :) I

On Tuesday 09 June 2009 14:34, Dan Gohman wrote: > Can you describe what problem you're trying to solve here? Does it > really need Regular Expressions? Yes. I want TableGen to be able to infer lots of stuff programmatically. This helps tremendously when specifying things like, oh, AVX. :) We could invent our own pattern matching syntax, but why?