search for: registermask

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

...; 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* @__assert_func> 0 0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8, TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0, Register:i32 %I18, Register:i32 %I17, Register:i32 %I16, Register:i32 %I15, RegisterMask:Untyped, 0x15c9bbcc8:1 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* @__assert_func> 0 0x15c9bb9f0: i32 = Register %I18 0x15c9bbac0: i32 = Register %I17 0x15c9bbb90: i32 = Register %I16 0x15c9bbc60: i32 = Register %I15 0x15c9bbd30: Untyp...

...TargetGlobalAddress<void (i8*, i32, i8*, i8*)* > @__assert_func> 0 > 0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8, > TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0, > Register:i32 %I18, Register:i32 %I17, Register:i32 %I16, Register:i32 %I15, > RegisterMask:Untyped, 0x15c9bbcc8:1 > 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* > @__assert_func> 0 > 0x15c9bb9f0: i32 = Register %I18 > 0x15c9bbac0: i32 = Register %I17 > 0x15c9bbb90: i32 = Register %I16 > 0x15c9bbc60: i32 = Register...

...etGlobalAddress: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:Untyped, 0x1ede6ae3510:1 0x1ede6ae3370: i32 = TargetGlobalAddress<i32 (i32)* @foo> 0 0x1ede6ae34a8: i32 = Register %I18 0x1ede6ae3578: Untyped = RegisterMask 0x1ede6ae3510: ch,glue = CopyToReg 0x1ede6ae3440, Register:i32 %I18, Constant:i32<42> 0x1ede6ae34a8: i32 =...

...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 = callseq_end t50, TargetConstant:i32<0>, TargetExternalSymbol:i32'__divdi3', t50:1 t52: i64,ch,glue = CopyFromReg t51, Register:i64 %reg0, t51:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1...

...ates regmask based on the actual register usage and if procedure with preserve_most cc does not use R11 and none callsite inside of function body then IPRA will mark R11 as preserved. Also IPRA produces RegMask which is super set of RegMask due to calling convention. I believe that __attribute__ ((registermask = ....)) can provide more flexibility compare to preserve_all or preserve_most CC in some case. So believe that we should try it out. -Vivek This CALL instruction register USE and DEF info should already be useful to the intra-procedural register allocator (allowing values live across these call...

...nction will be compiled in current module). > > > > In case you want to experiment with IPRA please apply > http://reviews.llvm.org/D21395 this patch before you begin. > > > > -Vivek > > > > Perhaps using some form of __attribute__ ? > Maybe __attribute__ ((registermask = ....)) ? > > > --Peter Lawrence. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160708/12b6da00/attachment.html>

...calling convention or the Optimized calling convention. This is the safe thing to do, and is why I will Only use “preserves_most” and “preserves_all” optimized calling conventions, As those will have been implemented by a back-end writer who is aware of All these compilations (as opposed to the “registermask=” calling convention Which is much less safe) I do however feel that IPRA in the whole-program case should not be restricted to Only scratch-becoming-save changes, I don’t have any data to support the notion, But it begs to be investigated, unless someone can somehow prove that it can’t help Perfo...

...ion 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 TargetConstant has number 15 -Operation callseq_end has number 16 -Operation Register has number 17 -Operation CopyFromReg has number 18 -Operation CopyToReg has number 19 -Operation Register...

...l IO instructions That only the assembler knows about. These functions typically don't Use any registers besides the incoming argument registers, IE they don't Need to use any additional callee-save nor caller-save registers. Perhaps using some form of __attribute__ ? Maybe __attribute__ ((registermask = ....)) ? --Peter Lawrence. From: vivek pandya [mailto:vivekvpandya at gmail.com] Sent: Wednesday, July 13, 2016 11:47 AM To: Lawrence, Peter <c_plawre at qca.qualcomm.com> Cc: mehdi.amini at apple.com; llvm-dev <llvm-dev at lists.llvm.org>; llvm-dev-request at lists.llvm.org;...

...ates regmask based on the actual register usage and if procedure with preserve_most cc does not use R11 and none callsite inside of function body then IPRA will mark R11 as preserved. Also IPRA produces RegMask which is super set of RegMask due to calling convention. I believe that __attribute__ ((registermask = ....)) can provide more flexibility compare to preserve_all or preserve_most CC in some case. So believe that we should try it out. -Vivek This CALL instruction register USE and DEF info should already be useful to the intra-procedural register allocator (allowing values live across these call...

...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,glue = callseq_end t16, TargetConstant:i64<32>, TargetConstant:i64<0>, t16:1 t20: ch = lifetime.start t17, TargetFrameIndex:i64<0> t21: i64 = Constant<96> t22: i64 = Constant<0> t24: v4i32,ch = load<LD16[%0](align=8)(dereferenceabl...

...hat case IPRA can have actual register usage info (if function will be compiled in current module). In case you want to experiment with IPRA please apply http://reviews.llvm.org/D21395 this patch before you begin. -Vivek > Perhaps using some form of __attribute__ ? > Maybe __attribute__ ((registermask = ....)) ? > > > --Peter Lawrence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160707/6e1f84c6/attachment.html>

...calling convention or the Optimized calling convention. This is the safe thing to do, and is why I will Only use “preserves_most” and “preserves_all” optimized calling conventions, As those will have been implemented by a back-end writer who is aware of All these compilations (as opposed to the “registermask=” calling convention Which is much less safe) I do however feel that IPRA in the whole-program case should not be restricted to Only scratch-becoming-save changes, I don’t have any data to support the notion, But it begs to be investigated, unless someone can somehow prove that it can’t help Perfo...

To reduce memory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias > On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > > I believe I've identified the problem with almabench but I haven't found the root cause in the compiler ye...

...n 03/03/19 1:30 AM, via llvm-dev wrote: > Hi, > > I'm having an error I've never seen before > > LLVM ERROR: Cannot select: t20: ch,glue = <<Unknown Target Node #284>> t11, TargetGlobalAddress:i32<i32 (i32, i32)* @add2> 0, Register:i32 $r4, Register:i32 $r5, RegisterMask:Untyped, t18:1 > > The IR is > > define i32 @add2(i32 %a, i32 %b) { > entry: > %tmp1 = icmp eq i32 %a, 0 > br i1 %tmp1, label %done, label %recurse > recurse: > %tmp2 = sub i32 %a, 1 > %tmp3 = add i32 %b, 1 > %tmp4 = call i32 @add2(i32 %tmp2, i32 %tmp...

...(metadata i16 %call, metadata !8, metadata !16), !dbg !17 tail call void @h(i16 %call) #2, !dbg !18 ret void, !dbg !19 } For the second call, the AArch64 ISel lowering produces a 32-bit CopyFromReg from w0. t18: ch,glue = AArch64ISD::CALL t15, TargetGlobalAddress:i64<i16 (...)* @g> 0, RegisterMask:Untyped, test.c:5:11 t19: ch,glue = callseq_end t18, TargetConstant:i64<0>, TargetConstant:i64<0>, t18:1, test.c:5:11 t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 Then, TargetLowering::LowerCallTo adds a truncate node since the function return type is i1...

...apple.com] Sent: 30 July 2015 01:14 To: Daniel Sanders Cc: Hans Wennborg (hans at chromium.org); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [LLVMdev] [3.7.0] Two late issues with cross compilation to mips To reduce memory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com<mailto:daniel.sanders at imgtec.com>> wrote: I believe I've identified the problem with almabench but I haven't found the r...

..., metadata !16), !dbg !17 > tail call void @h(i16 %call) #2, !dbg !18 > ret void, !dbg !19 > } > > For the second call, the AArch64 ISel lowering produces a 32-bit CopyFromReg from w0. > > t18: ch,glue = AArch64ISD::CALL t15, TargetGlobalAddress:i64<i16 (...)* @g> 0, RegisterMask:Untyped, test.c:5:11 > t19: ch,glue = callseq_end t18, TargetConstant:i64<0>, TargetConstant:i64<0>, t18:1, test.c:5:11 > t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 > > Then, TargetLowering::LowerCallTo adds a truncate node since the function...

> On Mar 14, 2018, at 7:55 PM, Se Jong Oh <sejooh at microsoft.com> wrote: > > Hi Jonas, > > Thanks for taking a look! It makes linear-dbg-value.ll pass for my target by producing DEBUG_VALUEs correctly. I also tried a simple function with few operations and confirmed DEBUG_VALUEs which are not produced without trasferDbgValues in SetPromotedInteger. That’s great news! Do