[PATCH] D76286: [X86][MC] Support enhanced relaxation for branch align

Kan Shengchen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 27 02:38:10 PDT 2020


skan added a comment.

In D76286#1940291 <https://reviews.llvm.org/D76286#1940291>, @reames wrote:

> I don't think this is a good idea.  Without evidence to the contrary, I would assume that this suffers from exactly the same memory overhead problems as the original rejected patch.  The basic challenge is that a MCInst is quite large (~144 bytes if my quick mental math is right).  And the containing RelaxableInst is a bit larger still.  The storage for a small encoded instruction in a DataFragment without fixups is ~2-6 bytes.  That's a huge difference.


I did some measurement for the memory usage, and will paste the data next week.

> An alternate approach is to explore allowing prefixes to be spliced into DataFragments.  This would require keeping something analogous to a Fixup with the offset, prefix, and maximum bytes to insert.

I don't want that DataFragment can change its size, it's very strange. And if we allow prefixes to be spliced into DataFragments, we have to add a vector member to DataFragment to record the position where each encoded instruction starts. It would increase the size of DataFragment even if we do not need prefix padding.

> Another idea would be a new fragment subclass for instructions which are paddable, but not relaxable.  Or possibly a compressed representation for RelaxableFragment (i.e. most of the space/generality appears to be overkill.)

Unless we don't need the MCInst member, we almost can not have a smaller fragment than RelaxableFragment to do the padding.
In addition, introducing a new kind of fragment would increase code complexity in `MCAssembler.cpp` , `X86AsmBackend::padInstruction` a lot.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76286/new/

https://reviews.llvm.org/D76286





More information about the llvm-commits mailing list