[PATCH] D97982: [MC] Introduce NeverAlign fragment type
Rafael Auler via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 15 18:33:23 PDT 2021
rafauler added a comment.
> Probably the simplest way to ensure that computeFragmentSize() is sane is to establish the following rule: it should never examine fragments after the current fragment in the section. If we logically need to examine any fragment after the current fragment, we need to do that using relaxation, inside MCAssembler::layoutSectionOnce. This means we can compute the "current" layout using a single pass computeFragmentSize() calls.
I checked the implementation here too, and, indeed, when there is a RelaxableFragment that was relaxed, it gets invalidated by marking "last valid fragment" as its predecessor.
This forces the assembler to call "layoutFragment" on that exact relaxable fragment, which in turn will always ask the predecessor to compute its size.
So the bottom line is: if you have a fragment like neveralign that depends on the size of its immediate successor, that's fine, but if it depends on information of any other successor, then, and only then, you need to implement it as a relaxable fragment.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97982/new/
https://reviews.llvm.org/D97982
More information about the llvm-commits
mailing list