[all-commits] [llvm/llvm-project] 29ccb1: [BranchAlign] Compiler support for suppressing bra...

[Philip Reames via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 29ccb12e2c12b6a50a1451ffdbf70fef29efda0e
      https://github.com/llvm/llvm-project/commit/29ccb12e2c12b6a50a1451ffdbf70fef29efda0e
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2020-01-08 (Wed, 08 Jan 2020)

  Changed paths:
    M llvm/include/llvm/MC/MCAsmBackend.h
    M llvm/include/llvm/MC/MCStreamer.h
    M llvm/lib/MC/MCAsmStreamer.cpp
    M llvm/lib/MC/MCObjectStreamer.cpp
    M llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
    M llvm/lib/Target/X86/X86MCInstLower.cpp
    A llvm/test/CodeGen/X86/align-branch-boundary-noautopadding.ll
    A llvm/test/CodeGen/X86/align-branch-boundary-suppressions.ll

  Log Message:
  -----------
  [BranchAlign] Compiler support for suppressing branch align

As discussed heavily in the original review (D70157), there's a need for the compiler to be able to selective suppress padding (either nop or prefix) to respect assumptions about the meaning of labels and instructions in generated code.

Rather than wait for syntax to be finalized - which appears to be a very slow process - this patch focuses on the compiler use case and *only* worries about the integrated assembler. To my knowledge, this covers all cases mentioned to date for clang/JIT support.

For testing purposes, I wired it up so that if the integrated assembler was using autopadding for branch alignment (e.g. enabled at command line) then the textual assembly output would contain a comment for each location where padding was enabled or disabled. This seemed like the least painful choice overall.

Note that the result of this patch effective disables the jcc errata mitigation for many constructs (statepoints, implicit null checks, xray, etc...) which is non ideal. It is at least *correct* and should allow us to enable the mitigation for the compiler. Once that's done, and a few other items are worked through, we probably want to come back to this an explore a bundling based approach instead so that we can pad instructions while keeping labels in the right place.

Differential Revision: https://reviews.llvm.org/D72303