[PATCH] D42616: [X86] Emit 15-byte NOPs on recent AMD targets, else default to 10-byte NOPs (PR22965)

Peter Cordes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 27 23:51:04 PST 2018


pcordes accepted this revision.
pcordes added a comment.
This revision is now accepted and ready to land.

15-byte NOP should be ok for VIA Nano2000/3000 as well, if anyone still cares about them: Agner says "Instructions with any number of prefixes are decoded without delay."  Nano3000 can even fuse a NOP with the preceding instruction, so it doesn't use any extra resources in the execution units.

While we're looking at NOP strategies; how hard would it be to get the built-in assembler to pad other instructions instead of just adding extra NOP padding?  https://stackoverflow.com/questions/48046814/what-methods-can-be-used-to-efficiently-extend-instruction-length-on-modern-x86

e.g. use a disp32 or imm32 when you could have used an imm8 or disp8 (or no displacement).  You'd want to be careful you didn't slow down decoding, and only pad within the last basic block before the alignment boundary.  (i.e. don't insert padding that moves a branch or branch target forwards, except for the branch target you're trying to align).  Intel's uop cache compresses constants according to their actual value, (64-bit, 32-bit, or 16-bit), not how they were encoded in the x86 instruction, so disp32 + imm32 doesn't make it worse for the uop cache than disp8 + imm8 in one instruction if the constants are the same.

Even if you don't reach the exact boundary you want, it could mean fewer NOPs, especially on targets without 15-byte NOPs.



================
Comment at: lib/Target/X86/X86.td:880
   FeatureLAHFSAHF,
+  FeatureFast15ByteNOP,
   FeatureFastPartialYMMorZMMWrite
----------------
Is this only setting the flag for btver2?  Bobcat (btver1)'s decoders are also fine with repeated prefixes, and I don't see that getting set anywhere.



Repository:
  rL LLVM

https://reviews.llvm.org/D42616





More information about the llvm-commits mailing list