[x86] Bug fix where a new iteration of Pass 1 wasn't always requested
Summary
This merge request fixes a case where an x86 peephole optimisation did not flag the compiler to run another iteration of Pass 1 upon a deep optimisation with MOV instructions, thus possibly missing out on other optimisations.
System
- Processor architecture: i386, x86_64
What is the current bug behavior?
Code under -O2 and above may not be as efficient as it could be.
What is the behavior after applying this patch?
Fewer optimisation opportunities are missed.
Relevant logs and/or screenshots
Most of the changes are from modifying registers to minimise pipeline stalls. For example, under -O4, x86_64-win64 in the inifiles
unit - before:
...
movq %rcx,%rbx
movq %rdx,%rsi
movq %r8,%rdi
movq %r9,%r12
movq %rdx,%rax
testq %rdx,%rdx
je .Lj951
movq -8(%rdx),%rax
.Lj951:
testq %rax,%rax
setgb %dl
movq %r8,%rax
testq %rdi,%rdi
je .Lj952
movq -8(%rdi),%rax
.Lj952:
...
After:
...
movq %rcx,%rbx
movq %rdx,%rsi
movq %r8,%rdi
movq %r9,%r12
movq %rdx,%rax
testq %rdx,%rdx
je .Lj951
movq -8(%rdx),%rax
.Lj951:
testq %rax,%rax
setgb %dl
movq %r8,%rax
testq %r8,%r8 ; <- %rdi changed to %r8
je .Lj952
movq -8(%r8),%rax ; <- %rdi changed to %r8
.Lj952:
...
The improvements likely give no improvement to execution speed due to the distance of the MOV instructions from the ones that are changed, but may provide a cascade of additional optimistions in some situations as well as in future development.
Additional Notes
The fix was made by setting the "force new iteration" flag, since the current instruction isn't actually changed. In addition, a nearby Result := True;
statement was changed into setting this flag due to the current instruction not being changed and control flow returning to the start of an internal while loop, which continues to do more work with the current instruction. In other words, this improves compiler speed by potentially removing an additional and unnecessary procedure call on the current instruction.