<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Addressing mode matching does not combine a 32 bit constant addition into a 64 bit address mode calculation"
href="https://llvm.org/bugs/show_bug.cgi?id=22970">22970</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Addressing mode matching does not combine a 32 bit constant addition into a 64 bit address mode calculation
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: X86
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dtc-llvm@scieneer.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>