Sub-optimal placement of loop exit blocks #50529
Description
| Bugzilla Link | 51185 |
| Version | trunk |
| OS | Windows NT |
| Attachments | test case |
| CC | @weiguozhi,@davidbolvansky,@DMG862,@preames,@shubhamnarlawar77,@sjoerdmeijer |
Extended Description
In the attached test case there's is a (fully unrolled) loop roughly of the following form
for ... {
if (cond) {
stuff();
break;
}
more_stuff();
}
when compiled for AArch64 with llc store.ll, the output looks like:
// iteration 0
cmp w11, w12
b.ne .LBB0_2
mov x11, xzr
b .LBB0_14
.LBB0_2:
...
// iteration 1
cmp w17, w12
b.ne .LBB0_6
add w10, w10, #​1
mov w11, #​1
b .LBB0_14
.LBB0_6:
...
// iteration 2
cmp w15, w12
b.ne .LBB0_10
add w10, w10, #​2
mov w11, #​2
b .LBB0_14
.LBB0_10:
...
// iteration 3
cmp w16, w12
b.ne .LBB0_15
add w10, w10, #​3
mov w11, #​3
// fallthrough
.LBB0_14:
// iterations 0, 1, 2, 3 early exit
...
i.e. the exit blocks are interspersed with "proper" body blocks and the
execution constantly jumps over them. In contrast, GCC's output looks like:
// iteration 0
...
cmp w6, w0
beq .L19
...
// iteration 1
...
cmp w2, w6
beq .L20
...
// iteration 2
...
cmp w6, w4
beq .L22
...
// iteration 3
...
cmp w2, w6
beq .L23
i.e. exit blocks an entirely stashed away and loop iterations are executed essentially like straight line code.