search for: mov64mi32

...ion. Is a jump table section with symbols associated with these new basic blocks the only option? In x86 assembly this would look something like: MOVQ 0x40044540, 0x8(%rsp) # Store address of trampoline basic block to stack The BuildMI looks like: BuildMI(MBB, MBIt, DL, TII->get(X86::MOV64mi32)) .addImm(0x1) // Scale .addReg(X86::RSP) // Base .addImm(0x8) // Disp .addMBB(my_target_mbb); // Source So far I have looked into the BuildMI API of LLVM and the only one that looks relevant is addMBB. While my LLVM pass compiles, my linker complains (and note that I am compiling with -fPIC): 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)

Hi, I had (naively?) expected that the instruction to move immediate to register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, MOV64ri32) would be marked with the flag MCID::MovImm via the X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). I do not see that to be the case. Can someone please tell me if my expectation is flawed? Is there a better/different way to determine to test for move immedia...

...; > ~Craig > > On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I had (naively?) expected that the instruction to move immediate to >> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >> MOV64ri32) would be marked with the flag MCID::MovImm via the >> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >> >> I do not see that to be the case. >> >> Can someone please tell me if my expectation is flawed? Is there a >&g...

...nstructions What are you trying to do? ~Craig On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had (naively?) expected that the instruction to move immediate to > register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, > MOV64ri32) would be marked with the flag MCID::MovImm via the > X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). > > I do not see that to be the case. > > Can someone please tell me if my expectation is flawed? Is there a > better/different way to d...

...On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> I had (naively?) expected that the instruction to move immediate to >>> register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, >>> MOV64ri32) would be marked with the flag MCID::MovImm via the >>> X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). >>> >>> I do not see that to be the case. >>> >>> Can someone please tell me if my expectation is f...

...Ops) { > + const MachineOperand &MO = MI.getOperand(CurOp++); > + unsigned Size = X86InstrInfo::sizeOfImm(Desc); > + if (MO.isImmediate()) > + FinalSize += sizeConstant(Size); > + else { > + bool dword = false; > + if (Opcode == X86::MOV64mi32) > + dword = true; > + if (MO.isGlobalAddress()) { > + FinalSize += sizeGlobalAddress(dword); > + } else if (MO.isExternalSymbol()) > + FinalSize += sizeExternalSymbolAddress(dword); > + else if (MO.isConstantPoolIndex()) > +...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And