[LLVMbugs] [Bug 22532] New: extra movz [x86, Intel, partial register update]

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22532
           Summary: extra movz [x86, Intel, partial register update]
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is related to the discussion in bug 22473 and may be the same issue as bug
17113 but with a simpler test case:

unsigned char f(unsigned char a, unsigned char b) { 
  return a == b; 
}

Or as IR:
define zeroext i8 @g(i8 zeroext %a, i8 zeroext %b) {
  %cmp = icmp eq i8 %a, %b
  %conv = zext i1 %cmp to i8
  ret i8 %conv
}

This becomes:
    cmpl    %esi, %edi
    sete    %al
    movzbl    %al, %eax  <--- is this zext good for perf?
    retq

There seems to be empirical evidence (see bug 22473) that zexts help
performance on SandyBridge because they help avoid partial register stalls.
This is despite Intel's docs (section 3.5.2.4 of the Optimization Reference
Manual) that suggest this isn't a big deal on SandyBridge or later.

Now, if this is a perf win for some Intel chips, then we're still not getting
it right all the time:

// C99 version: use bool return instead of unsigned char
#include <stdbool.h>
bool g(unsigned char a, unsigned char b) { 
  return a == b; 
}

Or as IR:
define zeroext i1 @g(i8 zeroext %a, i8 zeroext %b) #0 {
  %cmp = icmp eq i8 %a, %b
  ret i1 %cmp
}

This has no 'movzbl':
    cmpl    %esi, %edi
    sete    %al
    retq


And regardless of the perf question, we generate the 'movzbl' for f() with -Oz;
that can't be right.

-- 
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/20150210/d11a22e8/attachment.html>