search for: expandnod

...to see if anyone has any input. I would really like to get these landed soon if there are no objections. Hi Thomas, With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target due to these newly exposed intrinsics, I think these nodes should be handled in at least SelectionDAGLegalize::ExpandNode (for when the float type is legal but the operation is not) and DAGTypeLegalizer::SoftenFloatResult (for when the float type is not legal). Best, Alex

...g/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 4:20 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Sanjay, > > > > The issue that Michael is talking about is that in SelectionDAGLegalize::ExpandNode() > we’re doing this: > > > > case ISD::FP_TO_UINT: { > > SDValue True, False; > > EVT VT = Node->getOperand(0).getValueType(); > > EVT NVT = Node->getValueType(0); > > APFloat apf(DAG.EVTToAPFloatSemantics(VT), > >...

...oating point LibFunc calls > > > > Hi Andy, > > > > I’m interested to try out your patches… > > > > I understand the scope of FENV_ACCESS is relatively wide, however I’m > still curious if you managed to figure out how to prevent the > SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI > intrinsic from producing the predicate logic that incorrectly sets the > floating point accrued exceptions due to unconditional execution of the > ISD::FSUB node attached to the SELECT node. It’s a little above my head to > try to solve this issue...

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 anything. Ideas? -- Kevin P. Neal...

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20, Caldarale, Charles R wrote: > [...] > > That's because there is no llvm.ceil.* intrinsic defined in > include/llvm/Intrins...

...nd their performance is not an issue. I need basic i64 support only for functional correctness. > Any soft int stuff that lowering hasn't already implemented. Taking into account known issues with soft int staff... Why expansion of large MULs/etc into smaller ones is not default behavior of ExpandNode (LegalizeDAG)? (seems meaningful if i32 operation is Legal or Custom) Are there any plans to add that? Regards, Sergey Y.

On Wed, Mar 17, 2010 at 4:57 PM, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > Thanks, yes, I'm facing the same issue. > > Hm... seems there are no simple fixes. > I have to do one more i64 mul implementation to workaround aggressive > optimizations. > Is that correct? Is this the only way? This shouldn't be necessary, IMO. If you were going to

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

...hich seems odd -- it appears as if it ignored the Expand and just tried to continue onto selection for 64bit add as if it had been legal? And a different example: %res = shl i64 %0, 1 aborts with error: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3988: void {anonymous}::SelectionDAGLegalize::ExpandNode(llvm::SDNode*): Assertion `VT.isVector() && "Unable to legalize non-vector shift"' failed. So, it seems to me that a whole bunch of other code will need to be added or modified, too, to teach LLVM how to expand i64 to i32 operations for everything other than load/store, if I...

> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue()

Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the ISD::FSUB node attached to the SELECT node. It’s a little above my head to try to solve this issue with my current unde...

...to get these landed soon if there are no objections. >> >> Hi Thomas, >> >> With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target >> due to these newly exposed intrinsics, I think these nodes should be >> handled in at least SelectionDAGLegalize::ExpandNode (for when the >> float type is legal but the operation is not) and >> DAGTypeLegalizer::SoftenFloatResult (for when the float type is not >> legal). >> >> Best, >> >> Alex >> > -------------- next part -------------- An HTML attachment was scrubbe...

...ype the operands are promoted to as follows: > AddPromotedToType (ISD::ADD, MVT::i1, MVT::i64); > > For the "Expand" case, I believe you'll find what you're looking for in > the file: > lib/CodeGen/SelectionDAG/LegalizeDAG.cpp > and function SelectionDAGLegalize::ExpandNode(), but if I'm wrong here > perhaps others can correct me. > > Finally, MVT::f32 just states that the operand is a 32-bit single > precision floating point type. > > Nemanja > > On Sun, Jun 5, 2016 at 11:05 PM, Pedro Lopes via llvm-dev < > llvm-dev at lists.llvm.or...

Sorry, glad I'm in the right place. Before I start, I want to state that I'm a beginer and I'm trying to develop a backend by adapting an existent target to my platform. My first doubt is about the SelectionDAG and the TargetLowering class. When I use, for example: setOperationAction(ISD::ADD, MVT::i1, Promote); Is it correct to say that I'm promoting any operand used by the

...the Expand and just tried to continue onto selection for 64bit add as if it had been legal? >> >> And a different example: >> %res = shl i64 %0, 1 >> aborts with error: >> llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3988: void {anonymous}::SelectionDAGLegalize::ExpandNode(llvm::SDNode*): Assertion `VT.isVector() && "Unable to legalize non-vector shift"' failed. >> >> So, it seems to me that a whole bunch of other code will need to be added or modified, too, to teach LLVM how to expand i64 to i32 operations for everything other tha...

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

On 3/16/2016 12:53 PM, Rail Shafigulin wrote: > > On Wed, Mar 16, 2016 at 10:39 AM, Krzysztof Parzyszek via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 3/16/2016 12:36 PM, Krzysztof Parzyszek via llvm-dev wrote: > > If the action is "Expand", which will convert the operation into > > >

...urself. > > You can explicitly specify all of them as 'Expand' so LLVM will expand > 64-bit operation into 32-bit one. > > I am suspecting the code in SelectionDAGLegalize won't expand 64-bit operations to 32-bit ones. For example, I see this code in SelectionDAGLegalize::ExpandNode (near line 3090): case ISD::SUB: { EVT VT = Node->getValueType(0); assert(TLI.isOperationLegalOrCustom(ISD::ADD, VT) && TLI.isOperationLegalOrCustom(ISD::XOR, VT) && "Don't know how to expand this subtraction!"); If we mark the ac...

...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 X86 backend sets a table entry indicating that FP_TO_UINT should be expanded for these value types, but the actual expansion is in target-independent code. This is what it looks like in the version I last fetched: case ISD::FP_TO_UINT: { SDValue True, False;...

...onto selection for 64bit add as if it had been legal? >>>> >>>> And a different example: >>>> %res = shl i64 %0, 1 >>>> aborts with error: >>>> llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3988: void {anonymous}::SelectionDAGLegalize::ExpandNode(llvm::SDNode*): Assertion `VT.isVector() && "Unable to legalize non-vector shift"' failed. >>>> >>>> So, it seems to me that a whole bunch of other code will need to be added or modified, too, to teach LLVM how to expand i64 to i32 operations for ever...