[PATCH] D39840: [MC][X86] Code padding for performance stability - Branch instructions and targets alignment

Gadi Haber via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Nov 12 23:58:32 PST 2017


gadi.haber added inline comments.


================
Comment at: lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp:77
   const uint64_t MaxNopLength;
+
 public:
----------------
why is there a diff here? Did some unseen character was inserted?


================
Comment at: lib/Target/X86/MCTargetDesc/X86MCCodePadder.cpp:38
+      CPU != "core-avx-i" && CPU != "haswell" && CPU != "core-avx2" &&
+      CPU != "broadwell" && CPU != "skylake")
+    return;
----------------
isn't it safer just to check that the CPU is atom instead?
The rule is good for any future CPU by default.


================
Comment at: lib/Target/X86/MCTargetDesc/X86MCCodePadder.h:23
+
+/// The X86-specific class incharge of all code padding decisions for the X86
+/// target.
----------------
zvi wrote:
> *in charge
decisions --> policies ?


================
Comment at: lib/Target/X86/MCTargetDesc/X86MCCodePadder.h:41
+
+/// A padding policy that handles brach instructions (all types of jmps and
+/// calls) and the first instruction after a branch (i.e. first instruction in a
----------------
*branch


================
Comment at: lib/Target/X86/MCTargetDesc/X86MCCodePadder.h:107
+  ///
+  /// \returns true iff \p Inst is a branch (all types of jmps and calls).
+  bool instructionRequiresPaddingFragment(const MCInst &Inst) const override;
----------------
both direct and indirect?


Repository:
  rL LLVM

https://reviews.llvm.org/D39840





More information about the llvm-commits mailing list