[LLVMbugs] [Bug 18605] New: Usage of a copy of a register just after a mov instruction

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jan 24 09:47:52 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18605

            Bug ID: 18605
           Summary: Usage of a copy of a register just after a mov
                    instruction
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: jn at sirrida.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using a copy of a register just after a mov instruction may cost an extra cycle
on all but the very newest x86 processors (4th generation Intel Core).
On superscalar processors a mov instruction and a modification of the *source*
register thereof can be executed in parallel.
Typically for every line of the C code below we can reduce the number of used
cycles from 3 to 2 (measured on e.g. Intel i7 920, Intel Atom N450).
Even if the "correct order" is given the "wrong order" is produced.
Interestingly both GCC and ICC also show this strange behavior;
is there any reason to do it this way?

int test(int x) {
  int y;
  x ^= (x >> 2);
  x = (x >> 3) ^ x;
  x = x ^ (x >> 4);
  y = x;  x >>= 5;  x ^= y;  // almost the same but explicit
  return x;
  }
=>
    movl    %edi, %eax
    sarl    $2, %eax  // => sarl    $2, %edi
    xorl    %edi, %eax
    movl    %eax, %ecx
    sarl    $3, %ecx  // => sarl    $2, %eax
    xorl    %eax, %ecx
    movl    %ecx, %edx
    sarl    $4, %edx  // => sarl    $2, %ecx
    xorl    %ecx, %edx
    movl    %edx, %eax
    sarl    $5, %eax  // => sarl    $2, %edx
    xorl    %edx, %eax
    retq

-- 
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/20140124/4b0b9ea1/attachment.html>


More information about the llvm-bugs mailing list