[PATCH] D97982: [MC] Introduce NeverAlign fragment type

Kan Shengchen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 26 00:17:26 PDT 2021


skan added a comment.

In D97982#2652314 <https://reviews.llvm.org/D97982#2652314>, @Amir wrote:

> We've considered two options to integrate this functionality into LLVM:
>
> 1. Similar to JCC errata/BoundaryAlign fragment:
>
> Automatically insert NeverAlign into the section on cmp instruction, check if fuseable instruction follows it, and remove the fragment otherwise.
>
> 2. Similar to the current usage in BOLT: https://github.com/facebookincubator/BOLT/blob/68abc968b706b55585b1b8be315aef5d3bf90b1c/bolt/src/BinaryEmitter.cpp#L445
>
> Check basic block instructions in advance, only emit NeverAlign fragment if fuseable sequence is found.
>
> Pros and cons of each approach:
>
> 1. Pro is that macro-op fusion alignment will be applied to inline assembly as well as LLVM-produced MCs, the downside is that I've observed a lot of insertions and removals of NeverAlign fragment, which may hurt processing time.
> 2. Pro is that the check and insertion are happening once per basic block, the downside is that we need to integrate the logic for determining the insertion of this fragment higher up in the MCStreamer stack where we see the basic block.
>
> Thoughts? 
> +CC @skan

Some questions.

1. Is the purpose of this patch to avoid cmp ends and jmp starts exactly at 64b alignment? If it's the only purpose, I think we can reuse the BoundaryAlign fragment by adding a function like "needPadding" in MCAssembler.cpp.
2. Could you also upstream the code that inserts/remove the NeverAlign fragment and some test cases? Usage can help us determine if the design of the fragment is reasonable.


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

https://reviews.llvm.org/D97982



More information about the llvm-commits mailing list