search for: targetglobaladdress

...0>, t29:1 t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, t31:1 t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, t33:1 t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>, t35:1 t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, TargetConstant:i16<0>, t39:1 t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1 t43: ch = CLPISD::RET_FLAG t42:1 This node...

...t31, t24, FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, > t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>, > t35:1 > >   t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float > (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 > > t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, > TargetConstant:i16<0>, t39:1 > > t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1 > >   t43...

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

...gt;)> t9, t7, > t12, undef:i64 > t7: v64i32 = add t6, t4 > t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x > i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, > undef:i64 > t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x > i32]* @c> 0 > t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 > t3: i64 = undef > t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x > i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t...

...a to <64 x i32>*)](align=16)(tbaa=<0x30c5438>)> t9, t7, t12, undef:i64 t7: v64i32 = add t6, t4 t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, undef:i64 t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @c> 0 t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 t3: i64 = undef t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t16, undef:i64 t16: i64 = X86ISD::Wrappe...

...; FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, > FrameIndex:i16<2>, > t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, > FrameIndex:i16<3>, > t35:1 > >   t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float > (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 > > t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, > TargetConstant:i16<0>, t39:1 > > t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, > t41:1 > >...

...baa=<0x30c5438>)> t9, t7, t12, undef:i64 >> t7: v64i32 = add t6, t4 >> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, undef:i64 >> t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @c> 0 >> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >> t3: i64 = undef >> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t16, undef...

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

I have noticed that TargetGlobalAddress is generated for "source code" functions and TargetExternalSymbol is generated for builtins like __lshrdi3. What is the difference between TargetExternalSymbol and TargetGlobalAddress? Thanks, Rafael

Hi there, I try to JIT compile some bitcode and seeing the following error: LLVM ERROR: Cannot select: 0x28ec830: ch,glue = X86ISD::CALL 0x28ec7c0, 0x28ef900, Register:i32 %EDI, Register:i8 %AL, RegisterMask:Untyped, 0x28ec7c0:1 0x28ef900: i32 = X86ISD::Wrapper TargetGlobalAddress:i32<void (i8*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec520: i32 = TargetGlobalAddress<void (i8*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec670: i32 = Register %EDI 0x28ec750: i8 = Register %AL 0x28ec360: Untyped = RegisterMask 0x28ec7c0: ch,glue = CopyToReg 0x28ec6e0, Register:i...

...>>>> t7: v64i32 = add t6, t4 >>>> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >>>> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, >>>> undef:i64 >>>> t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>> @c> 0 >>>> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >>>> t3: i64 = undef >>>> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >>>> i32>*)](align=16)(tbaa=<0...

...c to <64 x i32>*)](align=16)(tbaa=<0x3817578>)> t8, t7, t11, undef:i64 t7: v64i32 = add t6, t4 t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x i32>*)](align=16)(tbaa=<0x3817578>)(dereferenceable)> t0, t11, undef:i64 t11: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @c> 0 t10: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 t3: i64 = undef t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x i32>*)](align=16)(tbaa=<0x3817578>)(dereferenceable)> t0, t13, undef:i64 t13: i64 = X86ISD::Wrappe...

...39; 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, TargetGlobalAddress:i32<void (i8*...

...>>>> t7: v64i32 = add t6, t4 >>>> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >>>> i32>*)](align=16)(tbaa=<0x3817578>)(dereferenceable)> t0, t11, >>>> undef:i64 >>>> t11: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>> @c> 0 >>>> t10: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >>>> t3: i64 = undef >>>> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >>>> i32>*)](align=16)(tbaa=<0...

hi Tim,guys, it was regarding splitting 16-bit ADDC to two 8-bit ADDC+ADDE. the 8-bit ADDE instruction is defined as: let Constraints="$dst=$op0",mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this

...o <64 >>>>>>>>>>>>>> x i32>*)](align=16)(tbaa=<0x3817578>)(dereferenceable)> t0, >>>>>>>>>>>>>> t11, undef:i64 >>>>>>>>>>>>>> t11: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 >>>>>>>>>>>>>> x i32]* @c> 0 >>>>>>>>>>>>>> t10: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >>>>>>>>>>>>>> t3: i64 = undef >>>&gt...

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

...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, Register:i32 %I18, RegisterMask:Un...

...;<Unknown Machine Node #65419>> 0x4972bd0, 0x49731d0, 0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)> Result DAG: SelectionDAG has 21 nodes: 0x49606f0: ch = EntryToken [ORD=1] [ID=0] 0x4972cd0: i8 = undef [ORD=1] [ID=2] 0x49735d0: i8 = Constant<1> [ID=3] 0x4977920: i8 = TargetGlobalAddress<i16* @b> 0 [ID=4] 0x4972fd0: i8 = SPISD::GLOBAL_TRANSFER 0x4977920 [ID=6] 0x49606f0: <multiple use> 0x4972fd0: <multiple use> 0x4972cd0: <multiple use> 0x4976c20: i8,ch = load 0x49606f0, 0x4972fd0, 0x4972cd0<LD1[@b](align=2)> [ID=8] 0x49606f0: &l...

Hello, I am learning to write a new backend for LLVM and have a few simple questions. 1) What are the differences between 'constant' and 'targetconstant', 'globaladdress' and 'targetglobaladdress'? It is not clear from the document when and which should be used. 2) On the processor I am working on, there is a 'move reg, mem_addr' instruction. When I try to match it using the pattern [(set Int32Regs::reg, tglobaladdr::mem_addr)]. the code generated by tblgen cannot be compiled...