[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