[LLVMbugs] [Bug 5997] New: [x86-64] regalloc not sharing 32-bit subregs of 64-bit regs aggressively

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Mon Jan 11 14:41:52 PST 2010


           Summary: [x86-64] regalloc not sharing 32-bit subregs of 64-bit
                    regs aggressively
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu

This (odd) testcase is a reduction of a larger pair of testcases from 256.bzip2
that I'll attach next.  This:

define i64 @test1a(i64 %A, i64 %B, i32* %P, i64 *%P2) nounwind {
  %C = add i64 %A, %B
  %D = trunc i64 %C to i32
  volatile store i32 %D, i32* %P
  %E = shl i64 %C, 32
  %F = ashr i64 %E, 32  
  volatile store i64 %F, i64 *%P2
  volatile store i32 %D, i32* %P
  ret i64 undef

LLC's into:

_test1a:                                                    ## @test1a
## BB#0:
        addq    %rsi, %rdi
                                                            ## kill: EDI<def>
        movl    %edi, (%rdx)
        movslq  %edi, %rax
        movq    %rax, (%rcx)
        movl    %edi, (%rdx)

This has unneccesarily high register pressure, it doesn't need to use RAX at
all.  I'd expect something like this:

        addq    %rsi, %rdi
        movl    %edi, (%rdx)
        movslq  %edi, %rdi
        movq    %rdi, (%rcx)
        movl    %edi, (%rdx)

Same # instructions, one fewer register.  This sort of thing happens quite
often for int induction variables (when dan's index promotion stuff doesn't
kick in) because GEP's implicitly sext their indices to i64, but the original
int is used for other things.  They should both share the same 64-bit GPR.

This is aka rdar://7529457

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list