search for: mov64rm

...400) #2 ret i64 %call } Which is probably the best representation to have at this relatively high level. At the machine level it looks like it is the register coalescer that is duplicating the constant. It transforms 0B BB#0: derived from LLVM BB %entry 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg1 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; mem:ST8[@p](tbaa=!"any pointer") GR64:%...

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

...ch is probably the best representation to have at this relatively high level. > > At the machine level it looks like it is the register coalescer that > is duplicating the constant. It transforms > > 0B BB#0: derived from LLVM BB %entry > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 > 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > %noreg; mem:LD8[GOT] GR64:%vreg1 > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > mem:ST8[@p](tbaa=!"...

...ation to have at this relatively > high level. > > > > At the machine level it looks like it is the register coalescer that > > is duplicating the constant. It transforms > > > > 0B BB#0: derived from LLVM BB %entry > > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > > <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 > > 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > > %noreg; mem:LD8[GOT] GR64:%vreg1 > > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > >...

...the end of the instruction, there is a "; mem:LD4..." * using MIR (llc -stop-before/-run-pass/etc.), at the end of the instruction, ":: (load 4…)” * using llc -asm-verbose, they are emitted as comments "# 4-byte Reload” MachineInstrs will have multiple operands, ex: > %5 = MOV64rm %0, 1, $noreg, 0, $noreg and in order to know which operand is what, the X86 backend uses some enums and helper functions so that they can write code like: > const MachineOperand &BaseReg = MI->getOperand(Op+X86::AddrBaseReg); > const MCOperand &BaseReg = MI.getOperand(Op+X86...

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

...e is a "; mem:LD4..." > * using MIR (llc -stop-before/-run-pass/etc.), at the end of the > instruction, ":: (load 4…)” > * using llc -asm-verbose, they are emitted as comments "# 4-byte Reload” > > MachineInstrs will have multiple operands, ex: > > > %5 = MOV64rm %0, 1, $noreg, 0, $noreg > > > and in order to know which operand is what, the X86 backend uses some > enums and helper functions so that they can write code like: > > > const MachineOperand &BaseReg = MI->getOperand(Op+X86::AddrBaseReg); > > > const MCOperand...

..., 0 MOV32mi <fi#4>, 1, %noreg, 0, %noreg, 4 %EDI<def> = MOV32rm <fi#3>, 1, %noreg, 0, %noreg %EDI<def,tied1> = SUB32rm %EDI<tied0>, <fi#4>, 1, %noreg, 0, %noreg, %EFLAGS<imp-def> MOV32mr <fi#5>, 1, %noreg, 0, %noreg, %EDI<kill> %RSI<def> = MOV64rm <fi#2>, 1, %noreg, 0, %noreg %RDI<def> = MOV64rm %RSI<kill>, 1, %noreg, 8, %noreg ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> CALL64pcrel32 <ga:@atoi>, <regmask>, %RSP<imp-use>, %RDI<imp-use,kill>, %EAX<imp-def&...

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

...%GS base addresss > mov %r15, %gs:0x0(%r14) //put value in R15 into R14:(%GS) [ (%GS) + > R14 ] > > -------------------------------------------------------------------------------------------------- > LLVM-MC -show inst gives: > movq (%gs), %r14 # <MCInst #1810 MOV64rm > # <MCOperand Reg:117> > # <MCOperand Reg:33> > # <MCOperand Imm:1> > # <MCOperand Reg:0> >...

After removing CALL64m, the resulting DAG has a cycle that cannot be scheduled. I've attached a PDF of the DAG before instruction selection (-view-isel-dags), and after instruction select (-view-sched-dags). Notice how the flag/chain relationships between MOV64rm and CALL64r make it impossible to schedule. Here's the code being compiled: define ccc void @ArgsFree() nounwind { entry: %0 = load void (i8*)** undef, align 4 call ccc void %0(i8* undef) nounwind unreachable } Is this a bug in LLVM, or is there something else I need to do than just re...

...-O3, I got this error (+ the dump of the function): > > # Machine code for function foo: Post SSA > Function Live Ins: %RDI in %vreg7 > > BB#0: derived from LLVM BB %entry > Live Ins: %RDI > %vreg7<def> = COPY %RDI; GR64:%vreg7 > %vreg1<def> = MOV64rm %vreg7, 1, %noreg, 8, %noreg; mem:LD8[%args.03](tbaa=<badref>) GR64:%vreg1,%vreg7 > TEST64rr %vreg1, %vreg1, %EFLAGS<imp-def>; GR64:%vreg1 > JE_4 <BB#3>, %EFLAGS<imp-use,kill> > Successors according to CFG: BB#3(12) BB#1(20) > > BB#1: >...

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

...s1542: MOV32ri64 [d1543<RDX>(+d3206,\~d3645",u1561):d1535] s1544: COPY [d1545<RDI>(+d3206,\~d3644",u1559):d1543, u1546<R13>(d785):] s1547: MOV32r0 [d1548<ESI>(+d3206,\~d3643",u1560):d1545, d1549<EFLAGS>!(d1540,\~d3642",):] s1550: MOV64rm [d1551<R11>(+d3206,\~d1554",u1562):d1548, u1552<RIP>(+d3206):u1537] s1553: CALL64pcrel32 __foo [\~d1554"<#1073741833>!(d1551,d1579,):, \~d3642"<#1073741833>!(d1549,,):, \~d3643"<#1073741833>!(d1548,,):, \~d3644"<#1073741833>!(d1545,,...

The size suffix thing is a weird quirk in our assembler I should look into fixing. Instructions in at&t syntax usually have a size suffix that is often optional For example: add %ax, %bx and addw %ax, %bx Are equivalent because the register name indicates the size. but for an instruction like this addw $1, (%ax) There is nothing to infer the size from so an explicit suffix is

...4 at 12160B -phi 5 at 13744B-phi 6 at 14480B-phi 7 at 18048B-phi 8 at 19792B-phi There is only one non-phi def. The (one) instruction defining the virtual register containing value #3 is at the top level of the function, not in a loop nest and not under a condition: 3472B %vreg637<def> = MOV64rm <fi#0>, 1, %noreg, 32, %noreg; mem:LD8[%37](align=32) GR64:%vreg637 dbg:file.c:46 [comments: Because of the multiple value numbers resulting from the phi defs, what appears at first to be a live interval that could be collapsed into one LiveRange cannot be so collapsed. The information I...

Hi Scott, That #1073741833 is a register mask. They are treated as aggregate registers (essentially sets of registers), so if it includes R9D and R11D, it will be treated as being aliased with both. These separate defs are there because they reach disjoint registers. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: Scott

On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote: > Hi Eli, > I have tried this, but the resulting tool-chain was broken. > There are only two references to "CALL64m": the definition in > X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > After commenting both out, compilation of a large application fails with: > llc: ScheduleDAG.cpp:462:

...n-referencing [1] and lightly edited to remove noise, with only variable locations for the 'i' variable. I've added some explanatory comments: DBG_PHI $rbx, 2 DBG_INSTR_REF 2, 0, !16, !DIExpression(), debug-location !23 ; This is the load from *curptr: renamable $rdi = MOV64rm renamable $r15, 8, renamable $rbx ; Call to ext, CALL64pcrel32 @ext, csr_64, [implicit defs] ; Loop increment: renamable $rbx = nuw nsw ADD64ri8 killed renamable $rbx, 1, debug-instr-number 1 DBG_INSTR_REF 1, 0, !16, !DIExpression(), debug-location !23 CMP64rr renamable $r14...

...-def,dead> ; srcLine 0 Virt folded mapped NewMI 0x98af530: ADD64mr <fi#165>, 1, %reg0, 0, %reg1599<kill>, %mreg23<imp-def,dead> ; srcLine 0 to %reg2559 Mapped %reg2559 and folded instruction: %reg1191<def> = MOV64rr %reg2559 ; srcLine 0 into: %reg1191<def> = MOV64rm <fi#165>, 1, %reg0, 0 ; srcLine 0 Virt folded mapped NewMI 0x92459e0: %reg1191<def> = MOV64rm <fi#165>, 1, %reg0, 0 ; srcLine 0 to %reg2559 ##### The remats identified above are all correct. Note that NO remats are defined for %reg2564 or %reg2565. Note the fold as well....