[LLVMbugs] [Bug 22970] New: Addressing mode matching does not combine a 32 bit constant addition into a 64 bit address mode calculation

[bugzilla-daemon at llvm.org]

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

            Bug ID: 22970
           Summary: Addressing mode matching does not combine a 32 bit
                    constant addition into a 64 bit address mode
                    calculation
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: dtc-llvm at scieneer.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following example is not compiled as well as possible for a 64 bit target:

int tst2(int *p, int i) { return p[(i & 0xfff) + 8]; }
        andl    $4095, %esi             # imm = 0xFFF
        addl    $8, %esi
        movl    (%rdi,%rsi,4), %eax

whereas:
int tst2(int *p, long i) { return p[(i & 0xfff) + 8]; }
        andq    $4095, %rsi             # imm = 0xFFF
        movl    32(%rdi,%rsi,4), %eax

In general this is doing the right thing, because the 32 bit addition might
overflow and wrap whereas the 64 bit addition in the addressing mode
calculation will not. However there does appear to be an opportunity here
because the high bits are known to be zero due to the masking operation so the
result of the addition can not overflow so is safe to move into the instruction
addressing mode calculation.

This is an important case for JSC translated code. The JS index is a 31 bit
unsigned value, that may have been masked etc, and code such as the above is
emitted for JS a[(i&c)+n]. While it would be possible to have JSC convert the
addition of a constant offset into a 64 bit operation during translation, this
seems like a useful optimization in general for the X86 llvm backend. Gcc
appears to optimize this.

There is some addressing mode matching logic in
lib/Target/X86/X86ISelDAGToDAG.cpp but it does not match this case because the
32 bit addition is blocked by a CopyFromReg.

Any hints on how to tackle this would be appreciated?

Could the 32 bit addition be converted to a 64 bit addition earlier? Would this
be appropriate, or should this be an optimization specific to the addressing
mode matching?

-- 
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/20150321/31e5901e/attachment.html>