search for: targetconstant

Here is a last example to illustrate my concern. The problem is about the lowering of node t13. Initial selection DAG: BB#0 '_start:entry' SelectionDAG has 44 nodes: t11: i16 = Constant<0> t0: ch = EntryToken t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64> t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64> t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, Constant:i32<8> t13: ch = store<Volatile ST4[@x1](tbaa=<0x3dbe41...

...The problem is about the lowering of node t13. > > Initial selection DAG: BB#0 '_start:entry' > > SelectionDAG has 44 nodes: > >   t11: i16 = Constant<0> > >                   t0: ch = EntryToken > >                 t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, > Constant:i32<64> > > t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, Constant:i32<64> > >             t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, > Constant:i32<8> > >           t13: ch = store<Vo...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...roblem is about the lowering of node t13. > > Initial selection DAG: BB#0 '_start:entry' > > SelectionDAG has 44 nodes: > >   t11: i16 = Constant<0> > >                   t0: ch = EntryToken > >                 t3: ch = llvm.clp.set.rspa t0, > TargetConstant:i16<392>, Constant:i32<64> > > t5: ch = llvm.clp.set.rspb t3, TargetConstant:i16<393>, > Constant:i32<64> > >             t8: ch = llvm.clp.set.rspsu t5, TargetConstant:i16<394>, > Constant:i32<8> > >           t13: ch = store<Vo...

...fn2v:entry' SelectionDAG has 122 nodes: t4: i64 = GlobalAddress<void (%class.F*)* @_Z10EmitLValuev> 0 t10: i64 = add Register:i64 %X1, Constant:i64<32> t0: ch = EntryToken t3: ch = lifetime.start t0, TargetFrameIndex:i64<1> t7: ch,glue = callseq_start t3, TargetConstant:i64<32>, TargetConstant:i64<0> t12: ch,glue = CopyToReg t7, Register:i64 %X3, FrameIndex:i64<1> t16: ch,glue = PPCISD::CALL_NOP t12, TargetGlobalAddress:i64<void (%class.F*)* @_Z10EmitLValuev> 0, Register:i64 %X3, Register:i64 %X2, RegisterMask:Untyped, t12:1 t17: ch...

...eater gathers to v64i32. for this i used; setOperationAction(ISD::MGATHER, MVT::v128i32, Expand); but i am getting error; LLVM ERROR: Cannot select: t4257: v128i32,ch = masked_gather<LD512[<unknown>](align=4)(tbaa=<0x30e7c78>)> t0, undef:v128i32, t4394, TargetConstant:i64<0>, t4312 t1061: v128i32 = undef t4394: v128i1 = BUILD_VECTOR TargetConstant:i1<-1>, TargetConstant:i1<-1>, TargetConstant:i1<-1>, TargetConstant:i1<-1>,........ why is that so? please help? -------------- next part -------------- An HTML attachment was scrub...

I am trying to removing a load to a TargetGlobalAddress in ISelDagToDag that my backend does not support. The TargetGlobalAddress is assumed to always be of ConstantInt or ConstantFP type, so this transformation is valid. I am correctly able to modify the dag and remove all of the uses of the node as specified in the attached before and after dot images. The nodes in question is the

...selectionDAG, the operations are effectively... -Operation EntryToken has number 0 -Operation Constant has number 1 -Operation FrameIndex has number 2 -Operation undef has number 3 -Operation store has number 4 -Operation GlobalAddress has number 5 -Operation GlobalAddress has number 6 -Operation TargetConstant has number 7 -Operation callseq_start has number 8 -Operation TargetGlobalAddress has number 9 -Operation Register has number 10 -Operation CopyToReg has number 11 -Operation RegisterMask has number 12 -Operation MipsISD::JmpLink has number 13 -Operation TargetConstant has number 14 -Operation Targ...

...0: ch = EntryToken t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0 t4: i64,ch,glue = CopyFromReg t2:1, Register:i64 %reg1, t2:1 t6: i64,ch,glue = CopyFromReg t4:1, Register:i64 %reg2, t4:1 t8: i64,ch,glue = CopyFromReg t6:1, Register:i64 %reg3, t6:1 t46: ch,glue = callseq_start t0, TargetConstant:i32<0> t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2 t48: ch,glue = CopyToReg t47, Register:i64 %reg1, t4, t47:1 t50: ch,glue = SHAVEISD::CALL t48, TargetExternalSymbol:i32'__divdi3', Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1 t51: ch,glue = cal...

Hi all. Currently if you launch some tool with "-debug" option, you got pretty detailed dump. Though the SelectionDAG nodes will dumped as its pointer values: 0xa1d7258: i32 = GlobalAddress<void (i32, ...)* @f> 0 0xa1d7368: i32 = undef [ORD=1] 0xa1d73f0: i32 = TargetConstant<12> [ORD=1] ... It is good if you want to look at memory contents by its address then. But if you just want to understand how the DAG looks 0xABRACADABRA annoying sometimes. This patch allows to see the DAG in more readable form: Node0: i32 = GlobalAddress<void (i32, ...)* @f> 0...

...s node has an i32 operand, and that's because we do the half-float load with an integer load instruction. And after this rewrite, we end up with this DAG: t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %0 t16: i32,ch = t2LDRHi12<Mem:LD2[%addr]> t2, TargetConstant:i32<0>, TargetConstant:i32<14>, Register:i32 %noreg, t0 t20: f16 = COPY_TO_REGCLASS t16, TargetConstant:i32<1> <~~~~~~~~~~~~~ PROBLEM HERE t12: f32 = VCVTBHS t20, TargetConstant:i32<14>, Register:i32 %noreg t7: i32 = VMOVRS t12, TargetConstant:i32<14&...

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

...s node has an i32 operand, and that's because we do the half-float load with an integer load instruction. And after this rewrite, we end up with this DAG: t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %0 t16: i32,ch = t2LDRHi12<Mem:LD2[%addr]> t2, TargetConstant:i32<0>, TargetConstant:i32<14>, Register:i32 %noreg, t0 t20: f16 = COPY_TO_REGCLASS t16, TargetConstant:i32<1> <~~~~~~~~~~~~~ PROBLEM HERE t12: f32 = VCVTBHS t20, TargetConstant:i32<14>, Register:i32 %noreg t7: i32 = VMOVRS t12, TargetConstant:i32<14&...

...actions with 'ISD::CALL' and 'ISD::RET_FLAG', but so far as I can tell I have revised these in the same way as the in-tree targets have adjusted their sources. The error I am seeing is: fatal error: error in backend: Cannot select: 0x15c9bbe00: ch,glue = callseq_end 0x15c9bbd98, TargetConstant:i32<0>, TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0, 0x15c9bbd98:1 0x15c9bb920: i32 = TargetConstant<0> 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* @__assert_func> 0 0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8, Ta...

Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

In SelectionDAG, what's the difference between getConstant and getTargetConstant? One creates a node with opcode Constant and the other with TargetConstant. What's the semantic difference? In X86ISelLowering I need to create a constant vector and put it in memory so I can reference it as an operand. I don't see any examples of doing this. Is it possible? If so, wh...

...; if ( neg ) y = - y; int rv = doSmth( y ); return neg ? - rv : rv; } Apparently, LLVM attempts to physically use the result of a CMP instruction through a function call by storing it on a temporary register. This is found before the doSmth function call, t30: i16 = CMPkr16 t4, TargetConstant:i16<0> t36: ch,glue = CopyToReg t0, Register:i16 $sr, t30 t32: i16 = NEGSETCC TargetConstant:i16<4>, t36:1 And this is generated after the call t35: ch,glue = CopyToReg t0, Register:i16 $sr, t30 t31: i16 = SELCC t19, t18, TargetConstant:i16<4>, t35:1 t21: ch,gl...

...#39;ISD::RET_FLAG', but so far as > I > can tell I have revised these in the same way as the in-tree targets have > adjusted their sources. > > The error I am seeing is: > > fatal error: error in backend: Cannot select: 0x15c9bbe00: ch,glue = > callseq_end 0x15c9bbd98, TargetConstant:i32<0>, > TargetGlobalAddress:i32<void > (i8*, i32, i8*, i8*)* @__assert_func> 0, 0x15c9bbd98:1 > 0x15c9bb920: i32 = TargetConstant<0> > 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* > @__assert_func> 0 > 0x15c9bbd98: ch,glue...

...[(my_ret)]> { let isReturn = 1; let usesCustomInserter = 1; } but when I compile the following C code: int foo(int); int bar() { return foo(42); } it crashes with the following dump: fatal error: error in backend: Cannot select: 0x1ede6ae3648: ch,glue = callseq_end 0x1ede6ae35e0, TargetConstant:i32<0>, TargetGlobalAddress:i32<i32 (i32)* @foo> 0, 0x1ede6ae35e0:1 0x1ede6ae33d8: i32 = TargetConstant<0> 0x1ede6ae3370: i32 = TargetGlobalAddress<i32 (i32)* @foo> 0 0x1ede6ae35e0: ch,glue = MyISD::CALL 0x1ede6ae3510, TargetGlobalAddress:i32<i32 (i32)* @foo> 0,...

...kael > > Are you trying to return multiple values? Yes, the intrisic returns a record %rec6 = type { i16, i16 } so at instructions selection the original call %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2) has been lowered to t6: i16,i16 = llvm.phx.divm.u16 TargetConstant:i16<3778>, t2, t4 and the instruction I want to select also returns two values def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins aNh_0_7:$src1, aNh_0_7:$src2)>; Both outs are i16. /Mikael