search for: x86isd

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

...let TargetPrefix = "x86" in { def int_x86_max_qb: GCCBuiltin<"__builtin_x86_max_qb">, Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrNoMem]>; } In /lib/Target/X86/X86SelLowering.h: add a sdnode max_qb, In /lib/Target/X86/X86SelLowering.cpp: case X86ISD::max_qb: return "X86ISD::max_qb"; In /lib/Target/X86/X86InstrInfo.td: def X86max_qb_flag : SDNode<"X86ISD::max_qb", SDTBinaryArithWithFlags, [SDNPCommutative]>; In /lib/Target/X86/X86InstrArithmetic.td: def max_qb : I<0xff,MRMSrcReg...

...ng++ -S -emit-llvm main.cpp && lli main.ll on Linux(Debian) > > #include <future> > > int main () { > return std::async([]{return 1;}).get(); > } > fails to run on lli due to the following error: > > LLVM ERROR: Cannot select: 0xd012e0: > i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8** @_ZSt15__once_callable> 0 [TF=10] > > 0xd020c0: i64 = TargetGlobalTLSAddress<i8** @_ZSt15__once_callable> 0 [TF=10] > In function: _ZSt9call_onceIMNSt13__future_base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseEN...

...a=<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&gt...

...ocal storage (notice TLS in the name). > > The same result can be reproduced by this simple program: > > thread_local int x = 0; > int main() { > return 0; > } > >When compiled into IR it produces similar error: > >LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19] > t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19] >In function: _ZTW1x interestingly this works on my machine. llvm-ir attached 2017-02-07 15:31 GMT+00:00 Alex Denisov <1101.debian at gmail.com>: > I’ve...

...;*)](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>)(derefe...

...re doing this, X86 legalize would have to be very careful to specifically form shuffles that it knew isel would turn into (e.g.) unpck operations. Now instead of forming specific carefully constructed shuffle masks (not making sure other code doesn't violate them) it can just directly form the X86ISD node. > 2. Sometimes DAGs are legal in some contexts but not others and it is a > pain to deal with. A good example is VBROADCAST, where a <0,0,0,0> > shuffle is natively supported if the source vector is in memory. > Otherwise it's not legal and manual lowering is req...

...t ([65 x i32]* @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...

...egalize would have to be very careful to specifically form shuffles > that it knew isel would turn into (e.g.) unpck operations. Now > instead of forming specific carefully constructed shuffle masks (not > making sure other code doesn't violate them) it can just directly form > the X86ISD node. Right. What I've presented would reverse this. Rather than making Legalize have to know about what table-driven isel can and cannot do, have table-driven isel run first, see what it can do and then leave the rest for manual selection. We would still keep the existing pre-table-driven-...

On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: > > > One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. > > Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node with the calling convention somehow? > > Dan, do you have any thoughts on how to communicate the calling convention and call clobbered registers to the eventual CALL MachineInstr? The simplest way would probably be to add separate X86ISD opcodes for each desired set of call-clobb...

All, As I've done more integrating of AVX work upstream and more tuning here, I've run across several things which are clunky in the current isel design. A couple examples I can remember offhand: 1. We have special target-specific operators for certain shuffles in X86, such as X86unpckl. I don't completely understand why but Bruno indicated it was to address inefficiecies.

...d by this simple program: >> > >> > thread_local int x = 0; >> > int main() { >> > return 0; >> > } >> > >> >When compiled into IR it produces similar error: >> > >> >LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP >> TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19] >> > t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19] >> >In function: _ZTW1x >> >> interestingly this works on my machine. >> >> llvm-ir attached >> >> >>...

Over one year passed now, did anybody made any progress regarding this issue? On 9 February 2017 at 16:33, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > I'm looking currently into a patch >

[Adding llvm-dev back to list] On 8 February 2017 at 11:12, Gaetano Checinski <gaetano.checinski at gmail.com> wrote: > Thanks for sharing your insights, > so in theory i could build an llvm pass that calls TargetLowering::LowerToTLSEmulatedModel for each llvm::Function and it should work if i link a runtime that provides __emultls_get_address. I'm afraid not, that function is

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

I'm looking currently into a patch <https://mailtrack.io/trace/link/60b02baa5e1b3d7ffe6fbb428b343be17c58c583?url=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fllvm%2Fcommit%2Fa9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2%23diff-0fa8ca8690e36a8dfd05f6b751955164R339&signature=222c65b9d92c011f> which has been written for JuliaLang and is supposed to fix TLS for linux. Unfortunately it is based on

...ng the conventional way (bumping the RSP); otherwise calling into a function that allocates the memory from the heap [1]. The stack pointer is not modified in the second case. I am trying to implement this by: a. Custom lowering DYNAMIC_ALLOCA in case segmented stacks are enabled. b. Creating a X86ISD::SEG_ALLOCA node in LowerDYNAMIC_STACKALLOC if segmented stacks are enabled. (Right now all LowerDYNAMIC_STACKALLOC on x86 does is check for Windows and lower the call to X86ISD::WIN_ALLOCA). c. Having EmitLoweredSegAlloca do the checks, (calling the external function if needed) and, in both the c...

...ve to be very careful to specifically form shuffles >> that it knew isel would turn into (e.g.) unpck operations. Now >> instead of forming specific carefully constructed shuffle masks (not >> making sure other code doesn't violate them) it can just directly form >> the X86ISD node. > > Right. What I've presented would reverse this. Rather than making > Legalize have to know about what table-driven isel can and cannot do, > have table-driven isel run first, see what it can do and then leave > the rest for manual selection. > > We would still...

...0cc518 [ORD=109] [ID=8] 0x30cc5a8: i32 = shl 0x30cc2d8, 0x30ccc68 [ORD=109] [ID=7] 0x30cc2d8: i32,ch = CopyFromReg 0x30a6168, 0x30cc908 [ORD=109] [ID=5] 0x30cc908: i32 = Register %vreg29 [ID=1] 0x30ccc68: i8 = Constant<2> [ID=4] 0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6] 0x30ccab8: i32 = TargetJumpTable<0> [ID=3] 0x30cc6c8: i32 = undef [ID=2] 0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6] 0x30ccab8: i32 = TargetJumpTable<0> [ID=3] In function: __atomic_compare_exchange clang: error: clang fron...

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