similar to: [LLVMdev] getConvertAction/setConvertAction

On Mar 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 =

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

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

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 simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

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 legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

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

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

On Oct 7, 2008, at 9:30 AM, Villmow, Micah wrote: > Chris, > Thanks for the help, this will help me with writing more patterns, > but I am still hitting another roadblock. I attempted what you > suggested and it fixed that issue, but then it started giving a > warning that there is an unknown node in the resulting pattern. > > // unsigned int: f64->i32 ==>

Chris, Thanks for the help, this will help me with writing more patterns, but I am still hitting another roadblock. I attempted what you suggested and it fixed that issue, but then it started giving a warning that there is an unknown node in the resulting pattern. // unsigned int: f64->i32 ==> f64->f32 + f32->i32 def : Pat<(i32 (fp_to_uint (f64 GPR:$src0))), (i32

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

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 > simplification.  There are still some issues with this patch, but does > the approach

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*

I assume the FP_TO_SINT, FP_TO_UINT use C "round to 0" convention? What about values out of range? I think C99 standard says these are undefined. Thanks, Dan

I am trying to get a multi instruction pattern to work and seem to be running into trouble. The problem itself is fairly simple. I need to go from 64bit floats to 32bit integers. As the backend doesn't support this natively but has a way of converting it, I'd prefer to get this working via tablegen. What I thought would work from the previous discussion is the following: def :

On Oct 6, 2008, at 5:42 PM, Villmow, Micah wrote: > I am trying to get a multi instruction pattern to work and seem to > be running into trouble. > The problem itself is fairly simple. I need to go from 64bit floats > to 32bit integers. As the backend doesn’t support this natively but > has a way of converting it, I’d prefer to get this working via > tablegen. > >

I'm working with Andrew on D43515 right now, and some of these unanswered questions are directly relevant to that patch. So.... On Fri, Feb 09, 2018 at 03:42:20PM +0100, Ulrich Weigand wrote: > C) Floating-point exceptions > If a mask bit in the floating-point status register is set, then all FP > instructions will *trap* whenever an IEEE exception condition is >

Is it possible to represent floating-point constants 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,

On Mon, 3 Sep 2018 at 13:31, Tim Northover <t.p.northover at gmail.com> wrote: > So the next step is to debug where Mips is producing those TruncIntFP > nodes. There'll be some constraint it's not checking or an unexpected > node type, probably related to -msingle-float. I'm afraid I'm not sure > what yet. > I'm reasonably sure the function producing that