search for: selectiondaglegalize

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

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141112/52592eeb/attachment.html>

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:

...(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)::SelectionDAGLeg...

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

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

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

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

...7ffff75b4570 "This action is not supported yet!", file=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/dmikushin/sandbox/src/llvm/lib/CodeGen/SelectionDA...

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

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

...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)::Sel...

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

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.getConstant(D...

...action is not supported yet!", > file=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/dmikushin/sandbox/src/llvm...

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

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

...s/libc.so.6(abort+0x1d5)[0x42028c55] /lib/tls/libc.so.6[0x42021043] /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/Debug/bin/llc((anonymous namespace)::SelectionDAGLegalize::HandleO...

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

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