[all-commits] [llvm/llvm-project] 451377: [ARM][Thumb2] Mark BTI-clearing instructions as sc...

[Victor Campos via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 45137766ca6be16b9bc6082eb9bedae7bc621437
      https://github.com/llvm/llvm-project/commit/45137766ca6be16b9bc6082eb9bedae7bc621437
  Author: Victor Campos <victor.campos at arm.com>
  Date:   2024-04-15 (Mon, 15 Apr 2024)

  Changed paths:
    M llvm/lib/Target/ARM/Thumb2InstrInfo.cpp
    M llvm/lib/Target/ARM/Thumb2InstrInfo.h
    A llvm/test/CodeGen/ARM/misched-branch-targets.mir

  Log Message:
  -----------
  [ARM][Thumb2] Mark BTI-clearing instructions as scheduling region boundaries (#87982)

Following https://github.com/llvm/llvm-project/pull/68313 this patch
extends the idea to M-profile PACBTI.

The Machine Scheduler can reorder instructions within a scheduling
region depending on the scheduling policy set. If a BTI-clearing
instruction happens to partake in one such region, it might be moved
around, therefore ending up where it shouldn't.

The solution is to mark all BTI-clearing instructions as scheduling
region boundaries. This essentially means that they must not be part of
any scheduling region, and as consequence never get moved:

 - PAC
 - PACBTI
 - BTI
 - SG

Note that PAC isn't BTI-clearing, but it's replaced by PACBTI late in
the compilation pipeline.

As far as I know, currently it isn't possible to organically obtain code
that's susceptible to the bug:

- Instructions that write to SP are region boundaries. PAC seems to
always be followed by the pushing of r12 to the stack, so essentially
PAC is always by itself in a scheduling region.
- CALL_BTI is expanded into a machine instruction bundle. Bundles are
unpacked only after the last machine scheduler run. Thus setjmp and BTI
can be separated only if someone deliberately run the scheduler once
more.
- The BTI insertion pass is run late in the pipeline, only after the
last machine scheduling has run. So once again it can be reordered only
if someone deliberately runs the scheduler again.

Nevertheless, one can reasonably argue that we should prevent the bug in
spite of the compiler not being able to produce the required conditions
for it. If things change, the compiler will be robust against this
issue.

The tests written for this are contrived: bogus MIR instructions have
been added adjacent to the BTI-clearing instructions in order to have
them inside non-trivial scheduling regions.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications