[llvm-dev] How to get emitted size of MachineInstr in MachineFunction pass?

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 25 12:53:50 PDT 2018


The final size of jumps is determined very late during binary emission
after all Machine passes have run. It's an iterative process as changing
the size of one jump can effect the size needed for other jumps that cross
it. This process is known as relaxation. The opcode starts as the
instruction known as JMP_1, JNE_1, JA_1, etc. and it is changed by the MC
layer to JMP_4, JNE_4, JA_4, etc. if the relative distance won't fit in one
byte.

I think you can force all jumps to be 5 bytes by passing -mrelax-all to
clang.

There's a informative blog post about assembly relaxation here
https://eli.thegreenplace.net/2013/01/03/assembler-relaxation

~Craig


On Thu, Oct 25, 2018 at 12:31 PM K Jelesnianski via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Dear Paul,
>
> I guess I used the wrong term when I said "alignment". I exactly am
> looking to ensure that all the instructions I am transforming (specifically
> jumps: JMP64r, JMP64m, etc) to become 5 bytes long, with JMP the length can
> vary from 2 bytes long to 5 from what I am seeing when I objdump the
> executable I am trying to instrument. I want to get the size of the
> MachineInstr I have created so that I know how many extra NOOPs I should
> insert afterwards to maintain a 5 byte total size.
>
> On Thu, Oct 25, 2018 at 2:58 PM <paul.robinson at sony.com> wrote:
>
>> There should be a way for you to specify a desired alignment, either on
>> the machine instruction itself, or as a directive inserted prior to the
>> instruction.  You should not need to compute the exact number of bytes
>> yourself, the MC assembler phase knows how to insert appropriate padding.
>>
>> --paulr
>>
>>
>>
>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *K
>> Jelesnianski via llvm-dev
>> *Sent:* Thursday, October 25, 2018 10:19 AM
>> *To:* llvm-dev
>> *Subject:* [llvm-dev] How to get emitted size of MachineInstr in
>> MachineFunction pass?
>>
>>
>>
>> Dear dev-list,
>>
>>
>>
>> I currently have a X86 machineFunctionPass and realized there are more
>> corner cases than I realized. I need to keep my custom jump transformations
>> aligned and therefore would like to fill the rest of the space with NOOPs.
>>
>>
>>
>> I understand that hexcode code ASM is emitted/encoded by the ASMPrinter.
>> In the past I have gotten the size via 2 compilations (1 to collect asm
>> size data, 2nd to perform fixup alignment where needed), but am looking for
>> a cleaner self contained solution.
>>
>>
>>
>> In the past I used this code, creating a function in X86AsmPrinter class
>>
>> unsigned int instSize;
>> SmallString<256> Code;
>> SmallVector<MCFixup, 4> Fixups;
>> raw_svector_ostream VecOS(Code);
>> CodeEmitter->encodeInstruction(Inst, VecOS, Fixups, STI);
>> instSize = Code.size();
>>
>> So far, I have already tried to get the size of the opcode at least via:
>>
>> size= MachineInstr->getDesc().getSize();
>>
>> but it returns zero, indicating that the encoding size cannot be
>> determined yet according to the LLVM doxygen, but why? We are already know
>> our target ISA is X86 and if I do a dump of the MachineInstr, the opcodes
>> and operands/registers seem already finalized....
>>
>>
>>
>> So the questions are:
>>
>> 1) Is it possible to temporarily encode a given MachineInstr to a
>> temporary buffer in a machineFunctionPass?? If so, how?
>>
>> 2) Is it possible to create an instance of CodeEmitter within a
>> machineFunctionPass to make it possible to run the above code? If so, how?
>>
>>
>>
>> Thanks in advance.
>>
>> Sincerely,
>>
>>
>>
>> K Jelesnianski
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181025/3f1c0be2/attachment.html>


More information about the llvm-dev mailing list