search for: expandnod

Displaying 20 results from an estimated 26 matches for "expandnod".

Did you mean: expandnode
2018 Nov 01
2
Proposed new min and max intrinsics
...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
2017 May 11
3
FENV_ACCESS and floating point LibFunc calls
...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), > >...
2017 May 11
2
FENV_ACCESS and floating point LibFunc calls
...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...
2018 Feb 13
1
Test for ISD::FP_ROUND_INREG?
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...
2013 Jan 20
0
[LLVMdev] On calling intrinsics
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...
2010 Mar 17
0
[LLVMdev] llvm-gcc promotes i32 mul to i64 inside __muldi3
...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.
2010 Mar 17
2
[LLVMdev] llvm-gcc promotes i32 mul to i64 inside __muldi3
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
2013 Jan 20
2
[LLVMdev] On calling intrinsics
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
2015 Apr 02
2
[LLVMdev] How to enable use of 64bit load/store for 32bit architecture
...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...
2017 Jan 23
2
returning from LowerOperation()
> 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()
2017 May 11
2
FENV_ACCESS and floating 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 with my current unde...
2018 Nov 08
2
Proposed new min and max intrinsics
...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...
2016 Jun 06
2
Doubts
...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...
2016 Jun 05
2
Doubts
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
2015 Apr 02
2
[LLVMdev] How to enable use of 64bit load/store for 32bit architecture
...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...
2012 Mar 02
1
[LLVMdev] vector shuffle emulation/expand in backend?
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
2016 Mar 16
3
how to type-legalize a dag
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 > > >
2012 Sep 07
1
[LLVMdev] 64 bit special purpose registers
...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...
2017 Apr 21
2
[cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long
...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;...
2015 Apr 03
2
[LLVMdev] How to enable use of 64bit load/store for 32bit architecture
...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...