search for: cmp64rr

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

...Successors according to CFG: BB#3(4) BB#2(124) > > BB#3: derived from LLVM BB %while.end > Predecessors according to CFG: BB#0 BB#2 > Successors according to CFG: BB#4 > > BB#4: derived from LLVM BB %while.end > Predecessors according to CFG: BB#3 BB#5 > CMP64rr %RDI, %RBP<kill>, %EFLAGS<imp-def> > JE_4 <BB#6>, %EFLAGS<imp-use,kill> > Successors according to CFG: BB#6 BB#5 > > BB#5: derived from LLVM BB %while.end > Predecessors according to CFG: BB#4 > MOV32mi %RDI<kill>, 1, %noreg, 0, %...

...gisterClass *AddrRegClass = getRegClassFor(MVT::i64); unsigned reg = MRI.createVirtualRegister(AddrRegClass); // Set the indice BuildMI(*MBB, MI, db, TII->get(X86::MOV64rr)).addReg(reg).addReg(X86::RSP); // Create the for loop condition BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::CMP64rr)).addReg(reg).addReg(X86::RBP); BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::JE_4)).addMBB(MBB_end); // Update phi node BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::PHI), reg).addReg(reg).addMBB(MBB).addReg(reg).addMBB(MBB_erase); // Erase content of stack BuildMI(*M...

...uildMI(*MBB, MI, db, TII->get(X86::MOV64rr)).addReg(regA).addReg(X86::RSP); // Check condition BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::PHI), regB).addReg(regA).addMBB(MBB).addReg(regC).addMBB(MBB_erase); BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::CMP64rr)).addReg(regB).addReg(X86::RBP); BuildMI(*MBB_cond, MBB_cond->end(), db, TII->get(X86::JE_4)).addMBB(MBB_end); // mov dword[reg], 0x0 BuildMI(*MBB_erase, MBB_erase->end(), db, TII->get(X86::MOV32mi)).addReg(regB).addImm(1).addReg(0).addImm(0).addReg(0).addImm(0); BuildMI...

...> = MOV32ri 0; GR32:%vreg4 MOV64rr %vreg7, %RSP; GR64:%vreg7 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %entry Predecessors according to CFG: BB#0 BB#2 %vreg8<def> = PHI %vreg7, <BB#0>, %vreg9, <BB#2>; GR64:%vreg8,%vreg7,%vreg9 CMP64rr %vreg8, %RBP, %EFLAGS<imp-def>; GR64:%vreg8 JE_4 <BB#3>, %EFLAGS<imp-use> Successors according to CFG: BB#2 BB#3 BB#2: derived from LLVM BB %entry Predecessors according to CFG: BB#1 MOV32mi %vreg8, 1, %noreg, 0, %noreg, 0; GR64:%vreg8 %vreg9<de...

...namable $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, renamable $rbx, implicit-def $eflags JCC_1 %bb.2, 5, implicit $eflags The label "debug-instr-number 1" on the ADD64ri8 identifies the ADD as corresponding to the loop increment, and the DBG_PHI for $rbx as the position where the loop PHI occurs. My key observation is...

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable