[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