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

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 4 23:12:47 PDT 2021


lebedev.ri added a comment.

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

> @lebedev.ri:
>
>> Where is this fragment going to be added? The alignment will differ per CPU.
>
> This fragment is inserted before first instruction in macro-fusion pair (cmp instruction in cmp+jcc pair).

That much was already clear :)

> Modern Intel Cores have a macro-fusion restriction that cmp+jcc shouldn't be split by a cache line boundary. It's OK to for cmp instruction to cross cache line boundary. Not all X86 cores have macro-fusion or this restriction,



> so the insertion policy and alignment is up to the MC client (BOLT or assembly programmer).

But this problem exists regardless of BOLT, so shouldn't this also happen without BOLT?

>> Do fragments only have the start point, or can they specify a range of instructions? If they can, then NeverAlign seems contrived to me. Perhaps this should instead be generalized into something like "ensure that this group of instructions doesn't cross ?-byte alignment"?
>
> This fragment only looks at the subsequent fragment (instruction) in the stream. It doesn't make sense for us to generalize to a range of instructions. There's BoundaryAlign fragment type that can handle alignment boundary crossing for macro-fusion pairs for Intel JCC erratum mitigation, or BundleAlign fragment that can align a group of instructions to the specified alignment (left, right alignment inside bundle, introduced by PNaCl to ensure control-flow integrity). These fragments are more general than NeverAlign, and come with a higher overhead for the client.

I understand that, i just think generalizing a bit may result in a somewhat more generally useful solution.


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

https://reviews.llvm.org/D97982



More information about the llvm-commits mailing list