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

[RKSimon]

Summary

We currently emit up to 15-byte NOPs on all targets (apart from Silvermont), which stalls performance on some targets with decoders that struggle with 2 or 3 more '66' prefixes.

This patch flags recent AMD targets (btver1/znver1) to still emit 15-byte NOPs but changes the default to 10 bytes for all other targets.

I'd like to add a 11-byte NOP feature as well for AMD bdver targets, but I'm not sure where we are with feature flag usage - although I could technically identify them with the FeatureXOP instead if that is OK?

[pcordes]

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.

lib/Target/X86/X86.td

880

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.

[RKSimon]

I can add the feature flag to Bobcat no problem - although the only place I can find any confirmation that its OK is in Agner's microarch doc. We don't have the Via Nano cpu targets any more.

What about the 11-byte NOPs for bdver - worth doing even though we'll either need to hijack FeatureXOP or use up another feature bit?

Not sure on padding through prefix/imm-extension - @craig.topper @spatel any ideas? We've recently been trying harder to reduce the size of immediates.......

[spatel]

In D42616#989981, @RKSimon wrote:

What about the 11-byte NOPs for bdver - worth doing even though we'll either need to hijack FeatureXOP or use up another feature bit?

Are we approaching a feature bit count limit? If not, I think it's better to make an explicit bit.

Not sure on padding through prefix/imm-extension - @craig.topper @spatel any ideas? We've recently been trying harder to reduce the size of immediates.......

What's the advantage of implicit padding via immediate widening vs. actual nops? I'm not familiar with how we do the padding currently, but it should be possible to choose the padding method in whatever pass handles that transform?

[craig.topper]

In D42616#990021, @spatel wrote:

In D42616#989981, @RKSimon wrote:

What about the 11-byte NOPs for bdver - worth doing even though we'll either need to hijack FeatureXOP or use up another feature bit?

Are we approaching a feature bit count limit? If not, I think it's better to make an explicit bit.

The feature bit limit is currently 192 and we're using 112. So we've got 80 more to go.

Not sure on padding through prefix/imm-extension - @craig.topper @spatel any ideas? We've recently been trying harder to reduce the size of immediates.......

What's the advantage of implicit padding via immediate widening vs. actual nops? I'm not familiar with how we do the padding currently, but it should be possible to choose the padding method in whatever pass handles that transform?

Actual nops take a decoder slot and emit a uop. Widening an instruction instead would avoid that.

Unfortunately, there's a not a pass that does the padding per se. Alignment is a field stored in the MachineBasicBlock until conversion to MC. At MC conversion the alignment is translated to an "alignment fragment". Instructions are immediately encoded into binary and stored in a "data fragment". The exception being relative jumps which start out with 1 byte offset and are stored in an "instruction fragment".

Once we have everything converted to fragments we go through an interative process to determine the final size and offset of every fragment. During this process we have to determine if a jump needs to be enlarged if the 1 byte offset isn't enough. If it does it has a ripple effect on every fragment after it. This can cause later jumps with negative offsets to need to be expanded as well. Once a jump has been expanded it won't be able to shrink again so eventually this process will terminate. Throughout the process the alignment fragment size is recalculated to satisfy the desired alignment. Once the iteration process finishes, the alignment fragment will be converted to NOPs and the jump instructions will be encoded. More information here https://eli.thegreenplace.net/2013/01/03/assembler-relaxation

So I don't know where immediate widening fits into that since we don't know the size of the nops we need until after most of the instructions have been encoded.

[RKSimon]

Enabled fast 15-byte NOPs for btver1

Added fast 11-byte NOPs for bdver* targets (since we're not as short of feature bits as I thought.....)

[RKSimon]

In case anyone has any more comments, I'll keep this open for another couple of days before submission.

[craig.topper]

lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp

355–356

Minor. Missing space between MaxNopLength and nops

[RKSimon]

Fix typo

[craig.topper]

LGTM

[reames]

Replying to a very old review thread...

Looking at this commit, I can't find any information about which platform triggered the switch from 15 byte to 10 byte nops by default. From what I can tell reading through Agner's guides, it really looks like modern Intel's should also handle the 15 byte form (as they can decode an unlimited number of prefixes w/o stalls). Was this simply missed in the review discussion, or is there some bit of context here I'm missing?

p.s. In the original discussion, padding instructions for alignment was mentioned as an alternative. Amusingly enough, that's what I'm now working on which triggered this question. (see D75203 and D75300)

[RKSimon]

In D42616#1913426, @reames wrote:

Looking at this commit, I can't find any information about which platform triggered the switch from 15 byte to 10 byte nops by default. From what I can tell reading through Agner's guides, it really looks like modern Intel's should also handle the 15 byte form (as they can decode an unlimited number of prefixes w/o stalls). Was this simply missed in the review discussion, or is there some bit of context here I'm missing?

IIRC the info for recent Intel targets wasn't available apart from a little info in Agner's docs and I think the Intel AOM recommended 10bytes. I'm not sure where the SLM limit came from and why its not all Atom arch but I seem to have kept it to 7bytes.

AMD's per-family SoGs usually recommend a upper limit so we used that info for each specific AMD cpu family.

As ever patches welcome for specific CPUs :-)

[reames]

Patch posted for Intel SandyBridge and later. https://reviews.llvm.org/D75945

lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp

bool X86AsmBackend::writeNopData(uint64_t Count, MCObjectWriter *OW) const {
   // This CPU doesn't support long nops. If needed add more.
   // FIXME: We could generated something better than plain 0x90.
   if (!STI.getFeatureBits()[X86::FeatureNOPL]) {
     for (uint64_t i = 0; i < Count; ++i)
       OW->write8(0x90);
     return true;
   }
 
-  uint64_t MaxNopLength = STI.getFeatureBits()[X86::ProcIntelSLM] ? 7 : 15;
+  // 15-bytes is the longest single nop instruction, but 10-bytes (2 prefixes)
+  // is commonly the longest that can be efficiently decoded.
+  uint64_t MaxNopLength = 10;
+  if (STI.getFeatureBits()[X86::ProcIntelSLM])
+    MaxNopLength = 7;
+  else if (STI.getFeatureBits()[X86::FeatureFast15ByteNOP])
+    MaxNopLength = 15;
 
-  // 15 is the longest single nop instruction.  Emit as many 15-byte nops as
-  // needed, then emit a nop of the remaining length.
+  // Emit as many MaxNopLengthnops as needed, then emit a nop of the remaining
+  // length.
   do {
     const uint8_t ThisNopLength = (uint8_t) std::min(Count, MaxNopLength);
     const uint8_t Prefixes = ThisNopLength <= 10 ? 0 : ThisNopLength - 10;
     for (uint8_t i = 0; i < Prefixes; i++)
       OW->write8(0x66);
     const uint8_t Rest = ThisNopLength - Prefixes;
     for (uint8_t i = 0; i < Rest; i++)
       OW->write8(Nops[Rest - 1][i]);

lib/Target/X86/X86.td

def FeatureFastVectorFSQRT
     : SubtargetFeature<"fast-vector-fsqrt", "HasFastVectorFSQRT",
                        "true", "Vector SQRT is fast (disable Newton-Raphson)">;
 // If lzcnt has equivalent latency/throughput to most simple integer ops, it can
 // be used to replace test/set sequences.
 def FeatureFastLZCNT
     : SubtargetFeature<
           "fast-lzcnt", "HasFastLZCNT", "true",
           "LZCNT instructions are as fast as most simple integer ops">;
-
-
+// If the target can efficiently decode NOPs upto 15-bytes in length.
+def FeatureFast15ByteNOP
+    : SubtargetFeature<
+          "fast-15bytenop", "HasFast15ByteNOP", "true",
+          "Target can quickly decode up to 15 byte NOPs">;
 // Sandy Bridge and newer processors can use SHLD with the same source on both
 // inputs to implement rotate to avoid the partial flag update of the normal
 // rotate instructions.
 def FeatureFastSHLDRotate
     : SubtargetFeature<
           "fast-shld-rotate", "HasFastSHLDRotate", "true",
           "SHLD can be used as a faster rotate">;
 
def : ProcessorModel<"btver2", BtVer2Model, [
   FeatureMOVBE,
   FeatureLZCNT,
   FeatureFastLZCNT,
   FeaturePOPCNT,
   FeatureXSAVE,
   FeatureXSAVEOPT,
   FeatureSlowSHLD,
   FeatureLAHFSAHF,
+  FeatureFast15ByteNOP,
   FeatureFastPartialYMMorZMMWrite
 ]>;
 
 // Bulldozer
 def : Proc<"bdver1", [
   FeatureX87,
   FeatureXOP,
   FeatureFMA4,
def: ProcessorModel<"znver1", Znver1Model, [
   FeatureFMA,
   FeatureFSGSBase,
   FeatureFXSR,
   FeatureNOPL,
   FeatureFastLZCNT,
   FeatureLAHFSAHF,
   FeatureLZCNT,
   FeatureMacroFusion,
+  FeatureFast15ByteNOP,
   FeatureMMX,
   FeatureMOVBE,
   FeatureMWAITX,
   FeaturePCLMUL,
   FeaturePOPCNT,
   FeaturePRFCHW,
   FeatureRDRAND,
   FeatureRDSEED,

lib/Target/X86/X86Subtarget.h

protected:
   /// True if its preferable to combine to a single shuffle using a variable
   /// mask over multiple fixed shuffles.
   bool HasFastVariableShuffle;
 
   /// True if there is no performance penalty to writing only the lower parts
   /// of a YMM or ZMM register without clearing the upper part.
   bool HasFastPartialYMMorZMMWrite;
 
+  /// True if there is no performance penalty for writing NOPs with up to
+  /// 15 bytes.
+  bool HasFast15ByteNOP;
+
   /// True if gather is reasonably fast. This is true for Skylake client and
   /// all AVX-512 CPUs.
   bool HasFastGather;
 
   /// True if hardware SQRTSS instruction is at least as fast (latency) as
   /// RSQRTSS followed by a Newton-Raphson iteration.
   bool HasFastScalarFSQRT;
 

lib/Target/X86/X86Subtarget.cpp

void X86Subtarget::initializeEnvironment() {
   IsUAMem32Slow = false;
   HasSSEUnalignedMem = false;
   HasCmpxchg16b = false;
   UseLeaForSP = false;
   HasPOPCNTFalseDeps = false;
   HasLZCNTFalseDeps = false;
   HasFastVariableShuffle = false;
   HasFastPartialYMMorZMMWrite = false;
+  HasFast15ByteNOP = false;
   HasFastGather = false;
   HasFastScalarFSQRT = false;
   HasFastVectorFSQRT = false;
   HasFastLZCNT = false;
   HasFastSHLDRotate = false;
   HasMacroFusion = false;
   HasERMSB = false;
   HasSlowDivide32 = false;

test/MC/MachO/x86_32-optimal_nop.s

 // CHECK:       0040: C3C3C30F 1F440000 C3000000 00000000  |.....D..........|
 // CHECK:       0050: C3C3660F 1F440000 C3000000 00000000  |..f..D..........|
 // CHECK:       0060: C30F1F80 00000000 C3000000 00000000  |................|
 // CHECK:       0070: C3C3C3C3 C3C3C3C3 C3000000 00000000  |................|
 // CHECK:       0080: C3C3C3C3 C3C3C366 0F1F8400 00000000  |.......f........|
 // CHECK:       0090: C3000000 00000000 00000000 00000000  |................|
 // CHECK:       00A0: C3C3C3C3 C3C3C366 0F1F8400 00000000  |.......f........|
 // CHECK:       00B0: C3000000 00000000 00000000 00000000  |................|
-// CHECK:       00C0: C3C3C3C3 C366662E 0F1F8400 00000000  |.....ff.........|
+// CHECK:       00C0: C3C3C3C3 C3662E0F 1F840000 00000090  |.....f..........|
 // CHECK:       00D0: C3000000 00000000 00000000 00000000  |................|
-// CHECK:       00E0: C3C3C3C3 6666662E 0F1F8400 00000000  |....fff.........|
+// CHECK:       00E0: C3C3C3C3 662E0F1F 84000000 00006690  |....f.........f.|
 // CHECK:       00F0: C3000000 00000000 00000000 00000000  |................|
-// CHECK:       0100: C3C3C366 6666662E 0F1F8400 00000000  |...ffff.........|
+// CHECK:       0100: C3C3C366 2E0F1F84 00000000 000F1F00  |...f............|
 // CHECK:       0110: C3000000 00000000 00000000 00000000  |................|
-// CHECK:       0120: C3C36666 6666662E 0F1F8400 00000000  |..fffff.........|
+// CHECK:       0120: C3C3662E 0F1F8400 00000000 0F1F4000  |..f...........@.|
 // CHECK:       0130: C3000000 00000000 00000000 00000000  |................|
-// CHECK:       0140: C3666666 6666662E 0F1F8400 00000000  |.ffffff.........|
+// CHECK:       0140: C3662E0F 1F840000 0000000F 1F440000  |.f...........D..|
 // CHECK:       0150: C3                                   |.|
 // CHECK:     )
 // CHECK:   }
 // CHECK:   Section {
 // CHECK:     Index: 1
 // CHECK:     Name: __const (5F 5F 63 6F 6E 73 74 00 00 00 00 00 00 00 00 00)
 // CHECK:     Segment: __TEXT (5F 5F 54 45 58 54 00 00 00 00 00 00 00 00 00 00)
 // CHECK:     Address: 0x160

 // CHECK: ]
 // CHECK: Indirect Symbols {
 // CHECK:   Number: 0
 // CHECK:   Symbols [
 // CHECK:   ]
 // CHECK: }
 // CHECK: Segment {
 // CHECK:   Cmd: LC_SEGMENT
-// CHECK:   Name: 
+// CHECK:   Name:
 // CHECK:   Size: 192
 // CHECK:   vmaddr: 0x0
 // CHECK:   vmsize: 0x174
 // CHECK:   fileoff: 340
 // CHECK:   filesize: 372
 // CHECK:   maxprot: rwx
 // CHECK:   initprot: rwx
 // CHECK:   nsects: 2

test/MC/X86/AlignedBundling/long-nop-pad.s

 # RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu -mcpu=pentiumpro %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - | FileCheck %s
 # RUN: llvm-mc -filetype=obj -triple x86_64-pc-linux-gnu -mcpu=pentiumpro -mc-relax-all %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - | FileCheck %s
 
 # Test that long nops are generated for padding where possible.
 
   .text
 foo:
   .bundle_align_mode 5
 
 # This callq instruction is 5 bytes long
   .bundle_lock align_to_end
   callq   bar
   .bundle_unlock
-# To align this group to a bundle end, we need a 15-byte NOP and a 12-byte NOP.
+# To align this group to a bundle end, we need a two 10-byte NOPs and a 7-byte NOP.
 # CHECK:        0:  nop
-# CHECK-NEXT:   f:  nop
+# CHECK-NEXT:   a:  nop
+# CHECK-NEXT:   14: nop
 # CHECK:   1b: callq
 
 # This push instruction is 1 byte long
   .bundle_lock align_to_end
   push %rax
   .bundle_unlock
-# To align this group to a bundle end, we need two 15-byte NOPs, and a 1-byte.
+# To align this group to a bundle end, we need three 10-byte NOPs, and a 1-byte.
 # CHECK:        20:  nop
-# CHECK-NEXT:   2f:  nop
+# CHECK-NEXT:   2a:  nop
+# CHECK-NEXT:   34:  nop
 # CHECK-NEXT:   3e:  nop
 # CHECK-NEXT:   3f: pushq

test/MC/X86/AlignedBundling/misaligned-bundle-group.s

 # RUN: llvm-mc -filetype=obj -triple i686-pc-linux-gnu -mcpu=pentiumpro %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - \
 # RUN:   | FileCheck -check-prefix=CHECK -check-prefix=CHECK-OPT %s
 # RUN: llvm-mc -filetype=obj -triple i686-pc-linux-gnu -mcpu=pentiumpro -mc-relax-all %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - \
 # RUN:   | FileCheck -check-prefix=CHECK -check-prefix=CHECK-RELAX %s
 
         .text
 foo:
         .bundle_align_mode 5
         push    %ebp # 1 byte
         .align  16
         .bundle_lock align_to_end
 # CHECK:            1:  nopw %cs:(%eax,%eax)
 # CHECK:            10: nopw %cs:(%eax,%eax)
-# CHECK-RELAX:      1f: nop
+# CHECK-RELAX:      1a: nop
 # CHECK-RELAX:      20: nopw %cs:(%eax,%eax)
-# CHECK-RELAX:      2f: nopw %cs:(%eax,%eax)
+# CHECK-RELAX:      2a: nopw %cs:(%eax,%eax)
 # CHECK-OPT:        1b: calll -4
 # CHECK-RELAX:      3b: calll -4
         calll   bar # 5 bytes
         .bundle_unlock
         ret         # 1 byte

test/MC/X86/AlignedBundling/misaligned-bundle.s

 # RUN: llvm-mc -filetype=obj -triple i686-pc-linux-gnu -mcpu=pentiumpro %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - \
 # RUN:   | FileCheck -check-prefix=CHECK -check-prefix=CHECK-OPT %s
 # RUN: llvm-mc -filetype=obj -triple i686-pc-linux-gnu -mcpu=pentiumpro -mc-relax-all %s -o - \
 # RUN:   | llvm-objdump -disassemble -no-show-raw-insn - \
 # RUN:   | FileCheck -check-prefix=CHECK -check-prefix=CHECK-RELAX %s
 
         .text
 foo:
         .bundle_align_mode 5
         push    %ebp          # 1 byte
         .align  16
 # CHECK:            1:  nopw %cs:(%eax,%eax)
 # CHECK-RELAX:      10: nopw %cs:(%eax,%eax)
-# CHECK-RELAX:      1f: nop
+# CHECK-RELAX:      1a: nop
 # CHECK-OPT:        10: movl $1, (%esp)
 # CHECK-RELAX:      20: movl $1, (%esp)
         movl $0x1, (%esp)     # 7 bytes
         movl $0x1, (%esp)     # 7 bytes
 # CHECK-OPT:        1e: nop
         movl $0x2, 0x1(%esp)  # 8 bytes
         movl $0x2, 0x1(%esp)  # 8 bytes
 # CHECK-RELAX:      3e: nop
 # CHECK-RELAX:      40: movl $2, 1(%esp)
         movl $0x2, 0x1(%esp)  # 8 bytes
         movl $0x2, (%esp)     # 7 bytes
 # CHECK-OPT:        3f: nop
 # CHECK-OPT:        40: movl $3, (%esp)
         movl $0x3, (%esp)     # 7 bytes
         movl $0x3, (%esp)     # 7 bytes
         ret

test/MC/X86/AlignedBundling/pad-bundle-groups.s

# CHECK-NEXT:   25: callq
 
   .align 16, 0x90
   callq   bar
   .bundle_lock
   callq   bar
   callq   bar
   callq   bar
   .bundle_unlock
-# And here we'll need a 11-byte NOP
+# And here we'll need a 10-byte NOP + 1-byte NOP
 # CHECK:        30: callq
 # CHECK:        35: nop
+# CHECK:        3f: nop
 # CHECK-NEXT:   40: callq
 # CHECK-NEXT:   45: callq
 
 
 

test/MC/X86/x86_long_nop.s

-# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s
-# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=pentiumpro | llvm-objdump -d -no-show-raw-insn - | FileCheck %s
-# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-apple-darwin10.0 -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s
-# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-apple-darwin8 -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP10
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=pentiumpro | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP10
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-apple-darwin10.0 -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP10
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-apple-darwin8 -mcpu=pentiumpro %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP10
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=slm %s | llvm-objdump -d -no-show-raw-insn - | FileCheck --check-prefix=LNOP7 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=silvermont %s | llvm-objdump -d -no-show-raw-insn - | FileCheck --check-prefix=LNOP7 %s
 # RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu -mcpu=lakemont %s | llvm-objdump -d -no-show-raw-insn - | FileCheck --check-prefix=NOP1 %s
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=btver2 %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=btver2 | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=x86_64-pc-linux-gnu -mcpu=znver1 %s | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
+# RUN: llvm-mc -filetype=obj -arch=x86 -triple=i686-pc-linux-gnu %s -mcpu=znver1 | llvm-objdump -d -no-show-raw-insn - | FileCheck %s --check-prefix=LNOP15
 
-# Ensure alignment directives also emit sequences of 15-byte NOPs on processors
+# Ensure alignment directives also emit sequences of 11 and 15-byte NOPs on processors
 # capable of using long NOPs.
 inc %eax
 .p2align 5
 inc %eax
-# CHECK: 0:  inc
-# CHECK-NEXT: 1:  nop
-# CHECK-NEXT: 10:  nop
-# CHECK-NEXT: 1f:  nop
-# CHECK-NEXT: 20:  inc
+# LNOP15: 0:  inc
+# LNOP15-NEXT: 1:  nop
+# LNOP15-NEXT: 10: nop
+# LNOP15-NEXT: 1f: nop
+# LNOP15-NEXT: 20: inc
+
+# LNOP10: 0:  inc
+# LNOP10-NEXT: 1:  nop
+# LNOP10-NEXT: b:  nop
+# LNOP10-NEXT: 15: nop
+# LNOP10-NEXT: 1f: nop
+# LNOP10-NEXT: 20: inc
 
 # On Silvermont we emit only 7 byte NOPs since longer NOPs are not profitable.
 # LNOP7: 0:  inc
 # LNOP7-NEXT: 1:  nop
 # LNOP7-NEXT: 8:  nop
 # LNOP7-NEXT: f:  nop
-# LNOP7-NEXT: 16:  nop
-# LNOP7-NEXT: 1d:  nop
-# LNOP7-NEXT: 20:  inc
+# LNOP7-NEXT: 16: nop
+# LNOP7-NEXT: 1d: nop
+# LNOP7-NEXT: 20: inc
 
 # On Lakemont we emit only 1 byte NOPs since longer NOPs are not supported/legal
 # NOP1: 0:  inc
 # NOP1-NEXT: 1:  nop
 # NOP1-NEXT: 2:  nop
 # NOP1-NEXT: 3:  nop
 # NOP1-NEXT: 4:  nop
 # NOP1-NEXT: 5:  nop