similar to: [LLVMdev] Proposal for adding rounding variant of fpto?i instructions

On Jul 12, 2010, at 9:28 AM, Anton Lokhmotov wrote: > Hi Peter, > >> I would appreciate comments/feedback on this proposal to extend the >> fpto?i instructions to support rounding. > I think this might be useful. Actually, LLVM specifies that fpto?i convert > their operand into the nearest (rounding towards zero) signed integer value. > Do you have other rounding modes

Hi Peter, > I would appreciate comments/feedback on this proposal to extend the > fpto?i instructions to support rounding. I think this might be useful. Actually, LLVM specifies that fpto?i convert their operand into the nearest (rounding towards zero) signed integer value. Do you have other rounding modes in mind? Currently I use custom metadata to represent conversions with other rounding

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 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

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());

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

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

Andy, Here is the left circular shift operator patch. I apologize to the reviewer in advance. The patch has a good bit of fine detail. Any comments/criticisms? Some caveats... 1) This is just the bare minimum needed to make the left circular shift operator work (e.g. no instruction combining). 2) I tried my best to select operator names in the existing style; please feel free to change them as

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

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 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. > >

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 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 :

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

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

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 >

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

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