[llvm-bugs] [Bug 35686] New: [X86] long nop generation is guarded incorrectly

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35686

            Bug ID: 35686
           Summary: [X86] long nop generation is guarded incorrectly
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: asb at lowrisc.org
                CC: llvm-bugs at lists.llvm.org

The intent of the HasNopl code in X86AsmBackend seems to be that long nops
should _not_ be generated when the target CPU is "generic" or "i686" (among
others). Consider the following input (from test/MC/X86/x86_long_nop.s):

inc %eax
.p2align 5
inc %eax

This generates long nops when there is no explicit -mcpu argument, because the
empty cpu string isn't tested when setting HasNopl:
./bin/llvm-mc -filetype=obj -triple=i686-pc-linux-gnu
../test/MC/X86/x86_long_nop.s | ./bin/llvm-objdump -d -no-show-raw-insn -

<stdin>:        file format ELF32-i386

Disassembly of section .text:
.text:
       0:       incl    %eax
       1:       nopw    %cs:(%eax,%eax)
      10:       nopw    %cs:(%eax,%eax)
      1f:       nop
      20:       incl    %eax

And short nops when explicitly passing -mcpu=generic:
./bin/llvm-mc -filetype=obj -triple=i686-pc-linux-gnu -mcpu=generic
../test/MC/X86/x86_long_nop.s | ./bin/llvm-objdump -d -no-show-raw-insn -

<stdin>:        file format ELF32-i386

Disassembly of section .text:
.text:
       0:       incl    %eax
       1:       nop
       2:       nop
       3:       nop
       4:       nop
       5:       nop
       6:       nop
       7:       nop
       8:       nop
       9:       nop
       a:       nop
       b:       nop
       c:       nop
       d:       nop
       e:       nop
       f:       nop
      10:       nop
      11:       nop
      12:       nop
      13:       nop
      14:       nop
      15:       nop
      16:       nop
      17:       nop
      18:       nop
      19:       nop
      1a:       nop
      1b:       nop
      1c:       nop
      1d:       nop
      1e:       nop
      1f:       nop
      20:       incl    %eax

See also: https://reviews.llvm.org/D41349 which exposes this issue ensuring
that "generic" is always given as the CPU string rather than the empty string.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171218/d919331a/attachment.html>