search for: mov64rr

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr %reg1230<kill> 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 328 %reg1135 = MOVSX64rr32 %reg1025 332 %reg1136 = MOV64rr %reg1135<kill> 336 %re...

...49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64r...

...as no MachineMemOperand? What about the reverse? > * Attaching a MachineMemOperand to an instruction that doesn’t reference any memory: From what I tried, the instruction has to be marked as “mayLoad / mayStore” (you can see them in X86InstrInfo.td) in order to pass the verifier: > $rbx = MOV64rr $rax :: (load 4) > bb.0: > liveins: $rax > $rbx = MOV64rr $rax; mem:LD4[<unknown>] > > # End machine code for function foo. > > *** Bad machine code: Missing mayLoad flag *** > - function: foo > - basic block: %bb.0 (0x7fc884017678) > - instruction: $r...

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

...:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64r...

...e? > > > > * Attaching a MachineMemOperand to an instruction that doesn’t reference > any memory: > > From what I tried, the instruction has to be marked as “mayLoad / > mayStore” (you can see them in X86InstrInfo.td) in order to pass the > verifier: > > > $rbx = MOV64rr $rax :: (load 4) > > > bb.0: > > liveins: $rax > > $rbx = MOV64rr $rax; mem:LD4[<unknown>] > > > > # End machine code for function foo. > > > > *** Bad machine code: Missing mayLoad flag *** > > - function: foo > > - basic block:...

...aving EmitLoweredSegAlloca do the checks, (calling the external function if needed) and, in both the cases, write the pointer to the allocated memory to RAX. If the function is called nothing extra needs to be done, since the return value stays at RAX. If the stack pointer was changed, I do a (X86::MOV64rr, X86::RAX).addReg(X86::RSP). d. Setting the value of the node to RAX in LowerDYNAMIC_STACKALLOC, making the last part of the function effectively look like this: // Reg is RAX or EAX, based on the subtarget Chain = DAG.getNode(X86ISD::SEG_ALLOCA, dl, NodeTys, Chain, Flag); Flag = Chain.getV...

...s the log of machine instructions before and after emitEpilogue for this function: * PEI::insertPrologEpilogCode: === >> before emitEpilogue - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> - insn: PROLOG_LABEL <MCSym=.Ltmp2> - insn: %RBP<def> = MOV64rr %RSP - insn: PROLOG_LABEL <MCSym=.Ltmp3> - insn: %RDI<def> = MOV64ri64i32 60910096 - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,d...

...: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&, llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. when attempting to allocate this machine function: entry: 4 %reg1024<def,dead> = MOV32rr %EDI<kill> 12 %reg1025<def,dead> = MOV64rr %RSI<kill> 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> 28 %reg1026<def> = MOV8ri 4 36 %reg1027<def> = FsFLD0SD 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> 52 %RDI<def> = MOV64rr %...

On Aug 26, 2010, at 12:59 PMPDT, Eric Christopher wrote: > On Aug 26, 2010, at 12:25 PM, Yuri wrote: >> On 08/26/2010 11:53, Eric Christopher wrote: >>> Could you get it to print out the instruction when it happens? >>> (just change the line above the error message to print it out to >>> errs()). >>> >>> It basically means that a pseudo

...instructions before and after > emitEpilogue for this function: > * PEI::insertPrologEpilogCode: === >> before emitEpilogue > - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> > - insn: PROLOG_LABEL <MCSym=.Ltmp2> > - insn: %RBP<def> = MOV64rr %RSP > - insn: PROLOG_LABEL <MCSym=.Ltmp3> > - insn: %RDI<def> = MOV64ri64i32 60910096 > - insn: %RAX<def> = MOV64ri > <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> > - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead>,...

...writeMBB(llvm::MachineBasicBlock&, > llvm::VirtRegMap&): Assertion `KillRegs[0] == Dst' failed. > > > when attempting to allocate this machine function: > > entry: > 4 %reg1024<def,dead> = MOV32rr %EDI<kill> > 12 %reg1025<def,dead> = MOV64rr %RSI<kill> > 20 ADJCALLSTACKDOWN 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, > %ESP<imp-use> > 28 %reg1026<def> = MOV8ri 4 > 36 %reg1027<def> = FsFLD0SD > 44 %reg1028<def> = LEA64r %reg0, 1, %reg0, <ga:.str1> > 52...

...= MOV64ri 32 CALL64pcrel32 <es:__morestack>, %RSP<imp-use> MORESTACK_RET Successors according to CFG: BB#0 BB#0: derived from LLVM BB %0 Predecessors according to CFG: BB#3 BB#4 %EAX<def> = MOV32ri 40040; flags: FrameSetup %RDX<def> = MOV64rr %RAX; flags: FrameSetup %RCX<def> = MOV64rr %RSP; flags: FrameSetup Successors according to CFG: BB#1 BB#1: derived from LLVM BB %0 Predecessors according to CFG: BB#0 BB#1 OR64mi8 %RCX, 1, %noreg, 0, %noreg, 0, %EFLAGS<imp-def>; flags: FrameSetup %RCX&l...

...#39;s not really possible to mix the two using tablegen? In the hardware, every instruction can either take an A register or a B register, in tablegen (as far as I can understand) this is not possible. I ended up creating instructions like MOV32ri (register immediate) MOV32rr (register register) MOV64rr, MOV64ri etc. I've done this for essentially every instruction. This kind of works, but there are issues. It results in unneeded copies between A registers and B registers. If a value is in an A register and the other is in a B, LLVM will do a copy between registers to make sure both register...

...uctions before and after emitEpilogue for this function: >> * PEI::insertPrologEpilogCode: === >> before emitEpilogue >> - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> >> - insn: PROLOG_LABEL <MCSym=.Ltmp2> >> - insn: %RBP<def> = MOV64rr %RSP >> - insn: PROLOG_LABEL <MCSym=.Ltmp3> >> - insn: %RDI<def> = MOV64ri64i32 60910096 >> - insn: %RAX<def> = MOV64ri <ga:@_ZN010HelloWorld4mainEPN13ContainerSVecE> >> - insn: TCRETURNri64 %RAX<kill>, 0, %RDI<kill>, %RAX<imp-def,dead&...

...r(MBB_end); MBB_cond->addSuccessor(MBB_erase); MachineRegisterInfo &MRI = MBB->getParent()->getRegInfo(); const TargetRegisterClass *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-&...

...rval end is 257 while %reg1330's interval start is 258. The merging code expects them to be equal in this case where the source register is dead after the copy. If we look at another copy where the source is dead but was NOT spilled, we see something different: Examining copy 420%reg1057 = MOV64rr %reg1297<kill> MOV64rr %reg1057<d> %reg1297 Ok from regalloc Real regs %reg1057 = %reg1297 Intervals: %reg1057,0 = [422,1034:0) 0 at 422-(1034) %reg1297,0 = [402,420:0)[420,422:1)[1074,1096:2) 0 at 402-(421) 1@?-(422) 2 at 1074-(1095) Notice how the end of the second value for %reg...

...tproc ## BB#0: ## %entry pushq %rbp ## <MCInst #2120 PUSH64r ## <MCOperand Reg:106>> Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp ## <MCInst #1491 MOV64rr ## <MCOperand Reg:106> ## <MCOperand Reg:114>> Ltmp4: .cfi_def_cfa_register %rbp movq %rdi, -8(%rbp) ## <MCInst #1482 MOV64mr ## <MCOperand Reg:...

...terClass *AddrRegClass = getRegClassFor(MVT::i64); unsigned regA = MRI.createVirtualRegister(AddrRegClass); unsigned regB = MRI.createVirtualRegister(AddrRegClass); unsigned regC = MRI.createVirtualRegister(AddrRegClass); // Set the indice BuildMI(*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);...

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>