This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen][MachineLastInstrsCleanup] fix INLINEASM_BR hazard
ClosedPublic

Authored by nickdesaulniers on Apr 25 2023, 2:09 PM.

Details

Summary

If the removable definition resides in an INLINEASM_BR target, the
reuseable candidate might not dominate the INLINEASM_BR.

bb0:
   INLINEASM_BR &"" %bb.1
   renamable $x8 = MOVi64imm 29273397577910035
   B %bb.2
   ...
 bb1:
   renamable $x8 = MOVi64imm 29273397577910035
   renamable $x8 = ADDXri killed renamable $x8, 2048, 0
 bb2:

Removing the second mov is a hazard when the inline asm branches to bb1.

Skip such replacements when the to be removed instruction is in the
target of such an INLINEASM_BR instruction.

We could get more aggressive about this in the future, but for now
simply abort.

This is causing a boot failure on linux-4.19.y branches of the LTS Linux
kernel for ARCH=arm64 with CONFIG_RANDOMIZE_BASE=y (KASLR) and
CONFIG_UNMAP_KERNEL_AT_EL0=y (KPTI).

Link: https://reviews.llvm.org/D123394
Link: https://github.com/ClangBuiltLinux/linux/issues/1837

Thanks to @nathanchance for the report, and @ardb for debugging.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2023, 2:09 PM
nickdesaulniers requested review of this revision.Apr 25 2023, 2:09 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2023, 2:09 PM
nickdesaulniers retitled this revision from [CodeGen][MachineLastInstrsCleanup] don't hoist loads above INLINEASM to [CodeGen][MachineLastInstrsCleanup] fix INLINEASM_BR hazard.
nickdesaulniers edited the summary of this revision. (Show Details)
nickdesaulniers added subscribers: ardb, nathanchance.
  • new change

(This will need to be backported to release/16.x since release/16.x contains 5ecd363)

efriedma accepted this revision.Apr 26 2023, 3:10 PM

If I'm following correctly, the issue is specifically with definitions after the INLINEASM_BR (which only execute in the fallthrough case)? In that case, you could theoretically still do some sort of analysis... but it gets a lot more complicated, so this fix seems sufficient. LGTM

This revision is now accepted and ready to land.Apr 26 2023, 3:10 PM
nickdesaulniers added a comment.EditedApr 26 2023, 3:12 PM

If I'm following correctly, the issue is specifically with definitions after the INLINEASM_BR (which only execute in the fallthrough case)? In that case, you could theoretically still do some sort of analysis... but it gets a lot more complicated, so this fix seems sufficient. LGTM

Yeah, this should be something quick that is low risk for a backport. I started hacking up the more precise fix, but it turns out you need to find the corresponding INLINEASM_BR in the pred MBB (could be multiple) and check which dominates. That doesn't seem as low risk as this for backporting.

Thanks for the review!

This revision was landed with ongoing or failed builds.Apr 27 2023, 1:46 PM
This revision was automatically updated to reflect the committed changes.