<html>
<head>
<base href="https://bugs.llvm.org/">
</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 - Missed opportunities for combining or eliminating sequential branches"
href="https://bugs.llvm.org/show_bug.cgi?id=46402">46402</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Missed opportunities for combining or eliminating sequential branches
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>khuey@kylehuey.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=23635" name="attach_23635" title="LLVM IR for jb X, je X and unconsolidated bounds checks.">attachment 23635</a> <a href="attachment.cgi?id=23635&action=edit" title="LLVM IR for jb X, je X and unconsolidated bounds checks.">[details]</a></span>
LLVM IR for jb X, je X and unconsolidated bounds checks.
I'm filing in this in the CodeGen component because it seems like peephole
optimizer should catch at least some of this this, but it may be that this
belongs elsewhere.
Using the latest nightly rustc (which is on LLVM 10), I see code sequences like
_ZN5x11rb8protocol3xkb21LatchLockStateRequest17try_parse_request17hb503842b081124b2E:
movq %rdi, %rax
shrq $40, %rsi
cmpb $5, %sil
jne .LBB4888_13
cmpq $2, %rcx
jb .LBB4888_16
je .LBB4888_16
cmpq $3, %rcx
je .LBB4888_16
cmpq $4, %rcx
je .LBB4888_16
cmpb $0, 4(%rdx)
setne %sil
cmpq $5, %rcx
je .LBB4888_16
movb 5(%rdx), %dil
cmpb $4, %dil
jae .LBB4888_13
cmpq $6, %rcx
je .LBB4888_16
cmpq $7, %rcx
je .LBB4888_16
cmpq $8, %rcx
je .LBB4888_16
cmpq $9, %rcx
je .LBB4888_16
andq $-2, %rcx
cmpq $10, %rcx
jne .LBB4888_12
.LBB4888_16:
movb $0, 1(%rax)
movb $1, %cl
movb %cl, (%rax)
retq
.LBB4888_13:
movb $1, 1(%rax)
movb $1, %cl
movb %cl, (%rax)
retq
.LBB4888_12:
movzwl (%rdx), %ecx
movb 2(%rdx), %r8b
movb 3(%rdx), %r9b
movb 6(%rdx), %r10b
cmpb $0, 9(%rdx)
movzwl 10(%rdx), %edx
movw %cx, 2(%rax)
movw %dx, 4(%rax)
movb %r8b, 6(%rax)
movb %r9b, 7(%rax)
movb %sil, 8(%rax)
movb %dil, 9(%rax)
movb %r10b, 10(%rax)
setne 11(%rax)
xorl %ecx, %ecx
movb %cl, (%rax)
retq
There's at least two missed opportunities to optimize branches here. The first
trivial one is that the adjacent `jb X; je X` could be combined into a single
`jbe X`.
The second, more complicated but bigger win is that a number of these branches
checking %rcx could be consolidated. At each point where we check %rcx all
values lower than the current comparison value have already been rules out. So
every one of those branches is not just a `je LBB4888_16` but effectively a
`jbe LBB4888_16`. If the compiler could figure that out it could remove
adjacent ones just leaving the last branch to LBB4888_16 in each sequence.
Identifying that would remove at least 50% of the branches in this function.
The LLVM IR that rustc produces for this function (as taken with llvm-extract)
is attached.</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>