search for: selectiondagleg

Displaying 20 results from an estimated 145 matches for "selectiondagleg".

2008 Jun 25
1
[LLVMdev] Assert in SelectionDAGLegalize when using arbitrary size integers
...port of arbitrary size integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059: llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): Assertion `NVT > VT && MVT::isInteger(NVT) == MVT::isInteger(VT) && "Cannot promote to smaller type!"' failed. The corresponding code is the following: SDOperand SelectionDAGLegalize::PromoteOp(SDOperand Op) { MVT::ValueType VT...
2014 Nov 12
2
[LLVMdev] [llvm][SelectionDAG] trivial patch: fix misprint in SelectionDAGLegalize::ExpandInsertToVectorThroughStack
Hi Owen! The "First store the whole vector" is without uses and will be deleted later. I've attached trivial patch to fix it. I have no commit access so if patch is OK, please, commit it . Danil. -------------- next part -------------- An HTML attachment was scrubbed... URL:
2009 Feb 24
3
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...(this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at PPCISelLowering.cpp:3200 #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at PPCISelLowering.cpp:3766 #9 0x0051bed6 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608 #10 0x0054837d in (anonymous namespace)::SelectionDAGLegalize::HandleOp (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519 #11 0x005485a5 in (anonymous namespace)::SelectionD...
2014 Nov 12
2
[LLVMdev] [llvm][SelectionDAG] trivial patch: fix misprint in SelectionDAGLegalize::ExpandInsertToVectorThroughStack
I detected this bug using test case from platform which is not currently supported on llvm targets. (Our team is porting llvm on new target). Creating the test case will take some extra time. I'll try to do it ASAP. Have you any ideas about the test case? (targets using ExpandInsertToVectorThroughStack, etc...) On Wed, Nov 12, 2014 at 8:29 PM, Owen Anderson <resistor at mac.com> wrote:
2020 Mar 02
4
RTLIB and Custom Library calls
...def Libcall enum so we have to define custom library calls. How is the ideal way of implementing the custom library calls? Providing us with a target backend having a similar functionality would also help us significantly. Say for a i64 type compare, does adding it in the RuntimeLibcalls.def enum, SelectionDAGLegalize::ConvertNodeToLibcall function, and the target ISelLowering Class solve our problem? Is it okay to modify RuntimeLibcalls.def and SelectionDAGLegalize::ConvertNodeToLibcall function? A starting point for processing lib calls other than the ISelLowering class would also help! Thank you in adva...
2014 Nov 17
2
[LLVMdev] [llvm][SelectionDAG] trivial patch: fix misprint in SelectionDAGLegalize::ExpandInsertToVectorThroughStack
Alright, go ahead with it. —Owen > On Nov 17, 2014, at 4:58 AM, Daniil Troshkov <troshkovdanil at gmail.com> wrote: > > Hi! > > I have not found test case. (It is because we have no target using "ExpandInsertToVectorThroughStack"). > But I tested it for target currently not included in llvm trunk. > > This fix correct and trivial, so I'm offering
2009 Feb 25
3
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...0x157a530, ResNo = 0}, DAG=@0x16088a0) > at PPCISelLowering.cpp:3200 > #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation > (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) > at PPCISelLowering.cpp:3766 > #9 0x0051bed6 in (anonymous > namespace)::SelectionDAGLegalize::LegalizeOp (this=0xbffff0e8, > Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608 > #10 0x0054837d in (anonymous > namespace)::SelectionDAGLegalize::HandleOp (this=0xbffff0e8, > Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519 > #11 0x005485a5 in (anonymous...
2012 Jun 27
2
[LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering
...=0x7ffff75b4128 "/home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp", line=1198) at /home/dmikushin/sandbox/src/llvm/lib/Support/ErrorHandling.cpp:98 #3 0x00007ffff6e9a612 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd300, Node=0x722820) at /home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1198 #4 0x00007ffff6e911ca in (anonymous namespace)::SelectionDAGLegalize::LegalizeDAG (this=0x7fffffffd300) at /home/d...
2012 Mar 23
2
[LLVMdev] Fixing VAARG on PPC64
.... I thought this would work > > because SDValue DAGTypeLegalizer::PromoteIntRes_VAARG seems to have > > the appropriate logic. Is this a bug, or am I misunderstanding how > > Promote works? > > IMHO, you are doing it right but it looks like ISD::VAARG is not > handled in SelectionDAGLegalize::PromoteNode() yet. DAGTypeLegalizer > is used to legalize "non-legal" types regardless of the operation > (need confirmation). Thanks! That makes sense, and looking more closely at the PromoteIntRes_VAARG code, it finds the type to which to promote by calling TLI.getRegisterT...
2009 Feb 25
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...530, ResNo = 0}, DAG=@0x16088a0) at >> PPCISelLowering.cpp:3200 >> #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation (this=0x1803d58, >> Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at >> PPCISelLowering.cpp:3766 >> #9 0x0051bed6 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp >> (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608 >> #10 0x0054837d in (anonymous namespace)::SelectionDAGLegalize::HandleOp >> (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519 >> #11 0x005485a5 in (anon...
2009 Feb 25
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...8, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at > PPCISelLowering.cpp:3200 > #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation (this=0x1803d58, > Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at > PPCISelLowering.cpp:3766 > #9 0x0051bed6 in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp > (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608 > #10 0x0054837d in (anonymous namespace)::SelectionDAGLegalize::HandleOp > (this=0xbffff0e8, Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519 > #11 0x005485a5 in (anonymous namespace)...
2012 Mar 23
0
[LLVMdev] Fixing VAARG on PPC64
...this would work >>> because SDValue DAGTypeLegalizer::PromoteIntRes_VAARG seems to have >>> the appropriate logic. Is this a bug, or am I misunderstanding how >>> Promote works? >> IMHO, you are doing it right but it looks like ISD::VAARG is not >> handled in SelectionDAGLegalize::PromoteNode() yet. DAGTypeLegalizer >> is used to legalize "non-legal" types regardless of the operation >> (need confirmation). > Thanks! That makes sense, and looking more closely at the > PromoteIntRes_VAARG code, it finds the type to which to promote by > ca...
2009 Jan 20
3
[LLVMdev] Shouldn't DAGCombine insert legal nodes?
...(and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this "feature". Moreover, the way all of SelectionDAGLegalize and DAGCombne's code is written, it's particularly difficult to "re- legalize" nodes unless one more legalization pass is invoked after DAGCombine. It's not like it's actually easy to load an i64 constant while maintaining the vector register uniformity that C...
2012 Jun 29
0
[LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering
..."/home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp", > line=1198) at /home/dmikushin/sandbox/src/llvm/lib/Support/ErrorHandling.cpp:98 > #3 0x00007ffff6e9a612 in (anonymous > namespace)::SelectionDAGLegalize::LegalizeOp (this=0x7fffffffd300, > Node=0x722820) > at /home/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1198 > #4 0x00007ffff6e911ca in (anonymous > namespace)::SelectionDAGLegalize::LegalizeDAG (this=0x7fffffffd300)...
2009 Dec 22
2
[LLVMdev] LegalizeDAG Error?
The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConst...
2006 Apr 26
1
[LLVMdev] LLC fail without gccld optimization on spec2000 int benchmarks
...;home/snir/jingyu/resources/llvm/build2/Debug/bin/llc(llvm::X86TargetLowering::LowerOperation(llvm::SDOperand, llvm::SelectionDAG&)+0x26c5)[0x83fe515] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDOperand)+0xa318)[0x851262c] /home/snir/jingyu/resources/llvm/build2/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::PromoteOp(llvm::SDOperand)+0x3030)[0x851c3cc] /home/snir/jingyu/resources/llvm/build2...
2018 Nov 01
2
Proposed new min and max intrinsics
...st wanted to bump this 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
2013 Aug 05
2
[LLVMdev] Promote MVT::f32 load/store to MVT::i32 cause infinite loop in LegalizeDAG?
...code. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote); AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. What is going on? I still have the following:(but I think that's fine) addRegisterClass(MVT::f32, &Opus::GR32RegClass); Thanks. (My LLVM is ~3 months old) -------------- next part -------------- An HTML attachment was scrubbed... URL:...
2009 Mar 02
1
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
...DAG=@0x16088a0) >> at PPCISelLowering.cpp:3200 >> #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation >> (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) >> at PPCISelLowering.cpp:3766 >> #9 0x0051bed6 in (anonymous >> namespace)::SelectionDAGLegalize::LegalizeOp (this=0xbffff0e8, >> Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608 >> #10 0x0054837d in (anonymous >> namespace)::SelectionDAGLegalize::HandleOp (this=0xbffff0e8, >> Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519 >> #11 0x00...
2008 Jun 06
3
[LLVMdev] Variable length condition code for SETCC and SELECT?
...t; 0x1501220: i1 = xor 0x1500f60, 0x15011b0 0x15012d0: ch = BasicBlock <bb20 0x14ff930> 0x15013e0: ch = brcond 0x1501330, 0x1501220, 0x15012d0 The setcc's are promoted to i32, since they are comparing i32 operands. The problem arises when the select (0x1500f60) is promoted by SelectionDAGLegalize::PromoteOp(), because the select's i1 is promoted to i8, which triggers an assert because select's arguments (i32) don't match the new, promoted value type. It's possible to convince the SELECT case inside of SelectionDAGLegalize::PromoteOp() that it should really look at t...