search for: mov32mr

...t;imp-use> %AL<def> = MOV8ri 0 CALL64pcrel32 <ga:@printf>, <regmask>, %RSP<imp-use>, %AL<imp-use,kill>, %RDI<imp-use,kill>, %EAX<imp-def> ADJCALLSTACKUP64 0, 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %ECX<def> = MOV32ri 25 MOV32mr <fi#8>, 1, %noreg, 0, %noreg, %EAX<kill>; mem:ST4[FixedStack8] %EAX<def> = COPY %ECX<kill> RET %EAX<imp-use,kill> if.else BB#2 %RDI<def> = LEA64r %RIP, 1, %noreg, <ga:@.str1>, %noreg ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP&lt...

The following is the code fragment after "# *** IR Dump Before Prolog/Epilog Insertion & Frame Finalization ***:". * MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 0 * * MOV32mr <fi#2>, 1, %reg0, 0, %reg0, %ECX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * MOV32mr %reg0, 1, %reg0, <ga:@one+4>, %reg0, %EAX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * ADJCALLSTACKDOWN32 8, %ESP<imp-def,dead>, %E...

...9;t have another computer I can test this on to see if that's it though. If this turns out to be a bug, rather than some misuse/misinterpretation of the function on my part I can resubmit it via that channel. The instructions I've noticed this occurring for are: MOV32mi, LEA32r, MOV32mr, and MOV32rm The length of LEA32r is calculated correctly some of the time. Same for MOV32mr and MOV32rm. The length of MOV32mi seems to always be wrong. An example breakdown of emitted Machine Instructions - the machine instructions are those outputted when I pass the -debug option to...

...reg, 80, %noreg; mem:LD8[%94] FR64:%vreg194 %vreg195<def> = MOV32ri 8; GR32:%vreg195 %EAX<def> = COPY %vreg195; GR32:%vreg195 WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg196<def> = COPY %ESP; GR32:%vreg196 MOV32mr %vreg196, 1, %noreg, 0, %noreg, %vreg16; mem:ST4[%114] GR32:%vreg196,%vreg16 %vreg197<def> = MOV32ri 72; GR32:%vreg197 %EAX<def> = COPY %vreg197; GR32:%vreg197 WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg198<d...

...ation rules by re-implementing SFI for the LLVM x86 backend based on the Google NaCl project. However, in trying to implement 32-byte code alignment, X86InstrInfo::GetInstSizeInBytes() is returning incorrect instruction sizes for certain instructions (that I have seen so far): MOV32mi, LEA32r, MOV32mr, and MOV32rm. MOV32mi is always calculated incorrectly while the remaining 3 are sometimes calculated incorrectly. Just to illustrate: 8d 9c 24 30 0a 00 00 LEA32r calculated length: 7 ok 8d 6c 24 28 LEA32r calcul...

...4] FR64:%vreg194 > %vreg195<def> = MOV32ri 8; GR32:%vreg195 > %EAX<def> = COPY %vreg195; GR32:%vreg195 > WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> > %vreg196<def> = COPY %ESP; GR32:%vreg196 > MOV32mr %vreg196, 1, %noreg, 0, %noreg, %vreg16; mem:ST4[%114] GR32:%vreg196,%vreg16 > %vreg197<def> = MOV32ri 72; GR32:%vreg197 > %EAX<def> = COPY %vreg197; GR32:%vreg197 > WIN_ALLOCA %EAX<imp-def,dead>, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use&g...

...quot;; dbg:l8.cpp:3:1 MOV32mi %RSP, 1, %reg0, 20, %reg0, 21; mem:ST4[%X] dbg:l8.cpp:1:1 MOV32mi %RSP, 1, %reg0, 16, %reg0, 22; mem:ST4[%Y] dbg:l8.cpp:1:1 MOV32mi %RSP, 1, %reg0, 12, %reg0, 23; mem:ST4[%Z] dbg:l8.cpp:1:1 %EDI<def> = MOV32rm %RSP, 1, %reg0, 20, %reg0; mem:LD4[%X] dbg:l8.cpp:1:1 MOV32mr %RSP, 1, %reg0, 12, %reg0, %EDI; mem:ST4[%Z] dbg:l8.cpp:1:1 %EAX<def> = MOV32rm %RSP, 1, %reg0, 16, %reg0; mem:LD4[%Y] dbg:l8.cpp:5:1 MOV32mr %RSP, 1, %reg0, 20, %reg0, %EAX; mem:ST4[%X] dbg:l8.cpp:5:1 %EDI<def> = ADD32rr %EDI, %EAX<kill>, %EFLAGS<imp-def,dead>; dbg:l8.cpp:6...

...ion [SP] fi#2: size=4, align=4, at location [SP] Function Live Ins: %R0 in %vreg0, %R1 in %vreg1 Function Live Outs: %R0 BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %vreg1<def> = COPY %R1<kill>; GR32:%vreg1 %vreg0<def> = COPY %R0; GR32:%vreg0 MOV32mr <fi#1>, 0, %vreg0<kill>; mem:ST4[%c.addr] GR32:%vreg0 MOV32mr <fi#2>, 0, %vreg1<kill>; mem:ST4[%d.addr] GR32:%vreg1 %vreg2<def> = MOV32rm <fi#1>, 0; mem:LD4[%c.addr] GR32:%vreg2 %vreg3<def> = CMPfri %vreg2<kill>, 0; SR1:%vreg3...

...;, 1, %NOREG, 0 %reg1025 = MOV32rm %reg1024, 1, %NOREG, 0 %reg1026 = MOVSX32rm8 %reg1025, 1, %NOREG, 0 %reg1027 = MOVSX32rm8 %reg1025, 1, %NOREG, 1 ADJCALLSTACKDOWN 8 %reg1028 = ADD32rr %reg1026, %reg1027 %reg1029 = IMUL32rr %reg1028, %reg1027 MOV32mr %ESP, 1, %NOREG, 4, %reg1029 MOV32mi %ESP, 1, %NOREG, 0, <ga:.str_1> CALLpcrel32 <ga:printf> ADJCALLSTACKUP 8, 0 %reg1030 = MOV32rr %EAX %reg1031 = IMPLICIT_DEF_GR32 %EAX = MOV32rr %reg1031 RET My allocator produces this mapping:...

...>; -def MOV16mr : I<0x89, MRMDestMem, (outs), (ins i16mem:$dst, GR16:$src), +def MOV16mr : I<0x89, MRMDestMem, (outs i16mem:$dst), (ins GR16:$src), "mov{w}\t{$src, $dst|$dst, $src}", [(store GR16:$src, addr:$dst)], IIC_MOV_MEM>, OpSize16; def MOV32mr : I<0x89, MRMDestMem, (outs), (ins i32mem:$dst, GR32:$src), -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150324/4e58d04d/attachment.html>

Hello! Can someone please tell me if is there an API (or some other way) to query MCInstrDesc to find out the type of its memory operands? As an example, consider the following description of MOV32mr (from X86InstrInfo.td) def MOV32mr : I<0x89, MRMDestMem, (outs), (ins i32mem:$dst, GR32:$src), "mov{l}\t{$src, $dst|$dst, $src}", [(store GR32:$src, addr:$dst)], IIC_MOV_MEM>, OpSize32; or that of MOVSX64rm (from X86InstrExtension.td) def MOVSX64rm...

...nment: 4 regInfo: .... frameInfo: .... body: - bb: 0 llbb: '%0' successors: [ 'bb#2', 'bb#1' ] liveIns: [ '%edi' ] instructions: - 'push64r undef %rax, %rsp, %rsp' - 'mov32mr %rsp, 1, %noreg, 4, %noreg, %edi' - .... .... - bb: 1 llbb: '%4' successors: [ 'bb#2' ] instructions: - '%edi = mov32rm %rsp, 1, %noreg, 4, %noreg' - .... .... - .... .... ......

On Wed, 21 Oct 2009, Lang Hames wrote: > There are any number of things that can go wrong in register allocation, so > it's hard for me to guess without seeing your code. > > Possible issues: > > 2) How are you making sure that interfering virtregs never receive the same > physreg? If you're using the LiveIntervals analysis (and the >

...%EBP, 1, %NOREG, -8 %ESI = MOV32rm %EBP, 1, %NOREG, -4 %ESP = MOV32rr %EBP %EBP = POP32r RET codeRepl (0xa5f4148, LLVM BB @0xa5ce310, ID#82): Predecessors according to CFG: 0xa60ca80 %EDI = INC32r %EDI %EAX = MOV32rm %EBP, 1, %NOREG, -268 MOV32mr %EAX, 1, %NOREG, 0, %EDI CALLpcrel32 <ga:test3_trueBlock_trueBlock.ret.exitStub_newFuncRoot.ce_trueBlock.ret.exitStub.ret.exitStub.ret.exitStub.ret7> %EAX = MOV32rm %EBP, 1, %NOREG, -268 %ESI = MOV32rm %EAX, 1, %NOREG, 0 %ESP = SUB32ri %ESP, 8 MOV32mr %...

...2rrr : M819Inst<(outs GR32:$dst),(ins GR32:$src1, GR32:$src2),"SUB.L\t{$dst,$src1 - $src2}",[(set GR32:$dst, (sub GR32:$src1, GR32:$src2))]>; def MOV32rm : M819Inst<(outs GR32:$dst), (ins memsrc:$src),"MOV.L\t{$dst, [$src]}",[(set GR32:$dst,(load addr:$src))]>; def MOV32mr : M819Inst<(outs), (ins memdst:$dst, GR32:$src),"MOV.L\t{[$dst], $src}",[(store GR32:$src, addr:$dst)]>; Am I misunderstanding something here? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

...; > - bb: 0 > > llbb: '%0' > > successors: [ 'bb#2', 'bb#1' ] > > liveIns: [ '%edi' ] > > instructions: > > - 'push64r undef %rax, %rsp, %rsp' > > - 'mov32mr %rsp, 1, %noreg, 4, %noreg, %edi' > > - .... > > .... > > - bb: 1 > > llbb: '%4' > > successors: [ 'bb#2' ] > > instructions: > > - '%edi = mov32rm %rsp, 1, %noreg, 4, %n...

..., <ga:DataStore> %EAX = MOV32rm %EBP, 1, %NOREG, -224 %EAX = ADD32ri8 %EAX, 40 MOV32mi %EAX, 1, %NOREG, 0, 0 MOV32mi %EAX, 1, %NOREG, 4, 1075576832 %ESP = SUB32ri %ESP, 16 %XMM0 = CVTSI2SDrr %EDI MOVSDmr %ESP, 1, %NOREG, 0, %XMM0 MOV32mr %EBP, 1, %NOREG, -268, %ESP ADD32mi8 %EBP, 1, %NOREG, -268, 4294967288 %ESP = MOV32rm %EBP, 1, %NOREG, -268 %ESI = MOV32rm %EBP, 1, %NOREG, -224 %ESI = ADD32ri8 %ESI, 16 MOV32mi %ESI, 1, %NOREG, 0, 0 MOV32mi %ESI, 1, %NOREG, 4, 1073741824 MOV3...

...rr8 %vreg9<kill>; GR32:%vreg1 GR8:%vreg9 %vreg10<def,tied1> = AND32ri %vreg0<tied0>, 1792, %EFLAGS<imp-def,dead>; GR32:%vreg10,%vreg0 ... BB_j: %vreg4<def,tied1> = AND32ri8 %vreg0<tied0>, 31, %EFLAGS<imp-def,dead>; GR32:%vreg4,%vreg0 MOV32mr %RIP, 1, %noreg, <ga:@b>, %noreg, %vreg1; mem:ST4[@b](align=8) GR32:%vreg1 Any suggestions are welcomed. Thanks, Wei.

...t;> >>> successors: [ 'bb#2', 'bb#1' ] >>> >>> liveIns: [ '%edi' ] >>> >>> instructions: >>> >>> - 'push64r undef %rax, %rsp, %rsp' >>> >>> - 'mov32mr %rsp, 1, %noreg, 4, %noreg, %edi' >>> >>> - .... >>> >>> .... >>> >>> - bb: 1 >>> >>> llbb: '%4' >>> >>> successors: [ 'bb#2' ] >>...