[LLVMbugs] [Bug 21353] New: spilled reload of bool mis-generated as "mov -x(%rbp),%r11d; and $0x1,%ebx"

[bugzilla-daemon at llvm.org]

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

            Bug ID: 21353
           Summary: spilled reload of bool mis-generated as "mov
                    -x(%rbp),%r11d; and $0x1,%ebx"
           Product: new-bugs
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: stephan.bergmann.secondary at googlemail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

At least when compiling with recent Clang trunk for Mac OS X x86-64,
unoptimised, I observe that for one expression

  it->GetSize( mbHorz, mbScroll, nMax, Size(mnMaxItemWidth, mnMaxItemHeight) )

where esp. mbHorz and mbScroll are single-bit bool members of some class,

  bool                mbDrag:1,
                      mbSelection:1,
                      mbCommandDrag:1,
                      mbUpper:1,
                      mbLower:1,
                      mbIn:1,
                      mbCalc:1,
                      mbFormat:1,
                      mbFullPaint:1,
                      mbHorz:1,
                      mbScroll:1,
                      mbLastFloatMode:1,
                      mbCustomize:1,
                      mbCustomizeMode:1,
                      mbDragging:1,
                      mbMenuStrings:1,
                      mbIsShift:1,
                      mbIsKeyEvent:1,
                      mbChangingHighlight:1;

the generated code (see below) correctly loads mbHorz and mbScroll into
registers (1, 2), then spills them to the stack (3, 4) across the embedded call
to the Size constructor (5), but when it loads them back in from the stack it
does so as

  mov    -0x840(%rbp),%r11d
  and    $0x1,%ebx

each (6, 7), i.e., loading them into dead sink %r11d and clobbering %ebx (which
isn't even pushed/poped in this function's pro-/epilogue, even though it must
be callee-saved), instead of loading them into %rsi resp. %rdx to pass as args
to the outer call to ImplToolItem::GetSize:

  lea    -0x658(%rbp),%rdi
  lea    -0x528(%rbp),%rax
  mov    %rax,-0xb0(%rbp)
  mov    -0xb0(%rbp),%rax
  mov    (%rax),%rax
  mov    -0x6f8(%rbp),%rcx
  mov    0x460(%rcx),%edx
  shr    $0x9,%edx
  and    $0x1,%edx                   # (1)
  mov    0x460(%rcx),%esi
  shr    $0xa,%esi
  and    $0x1,%esi                   # (2)
  mov    -0x518(%rbp),%rcx
  mov    -0x6f8(%rbp),%r8
  mov    0x3f8(%r8),%r9
  mov    0x400(%r8),%r10
  mov    %esi,-0x83c(%rbp)           # (3)
  mov    %r9,%rsi
  mov    %edx,-0x840(%rbp)           # (4)
  mov    %r10,%rdx
  mov    %rax,-0x848(%rbp)
  mov    %rcx,-0x850(%rbp)
  callq  0x106565700 <_ZN4SizeC1Ell> # (5)
  lea    -0x658(%rbp),%r8
  mov    -0x840(%rbp),%r11d          # (6)
  and    $0x1,%ebx
  mov    -0x83c(%rbp),%r11d          # (7)
  and    $0x1,%ebx
  mov    -0x848(%rbp),%rdi
  mov    %esi,-0x840(%rbp)
  mov    %edx,-0x83c(%rbp)
  mov    -0x850(%rbp),%rcx
  callq  0x1066efa60 <_ZN12ImplToolItem7GetSizeEbblRK4Size>

Unfortunately, I haven't been able yet to strip this down to something
manageable.

-- 
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/20141023/7794c979/attachment.html>