Currently, there's an optimisation that tries to relocate MOV
instructions so they appear before CMP and TEST instructions (you can
see it occurring in the code sample). This is usually generated by the
"J(c)Mov0JmpMov1 -> Set(c)" optimisation if the destination is not an
8-bit register, in which case, moving the MOV instruction so it appears
before CMP (so long as it doesn't share any registers with it) aids
optimisation if it's something like "movl $0,%eax", which can't be
encoded as "xorl %eax,%eax" if the FLAGS register is in use.
Macrofusion is an interesting point. I'll have to look into that one.
The only instructions that are moved in this "common instruction"
optimisation are ones that don't touch the FLAGS register, but only MOV
instructions are currently moved to appear before CMP and TEST
instructions if possible. In truth, any instruction that doesn't modify
the flags and doesn't share a register with the CMP/TEST instruction can
be moved, and can usually be executed in parallel with the comparison
(using another ALU, for example).
It might be that I have to add an extra Pass 2 optimisation that detects
"CMP/MOV/Jcc" triplets that remain and "unoptimise" the MOV/Jcc pair in
order to aid macrofusion.
Thanks for the insight Stefan.
Gareth aka. Kit
On 01/10/2021 19:00, Stefan Glienke via fpc-devel wrote:
Keep in mind that usually test/cmp and jcc instructions are macrofused
but only if they are directly adjacent.
Am 01.10.2021 um 18:10 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
I've started playing around with an optimisation on x86 platforms
that looks for common instructions that appear on both branches of a
Jcc instruction (i.e. after the label it jumps to and after the jump
itself), and so far I'm having a lot of success. For example, in the
Math unit - before:
...
# Peephole Optimization: %rdx = %rdi; removed unnecessary instruction
(MovMov2MovNop 6b}
call fpc_do_is
testb %al,%al
je .Lj196
movq %rdi,%rdx
movq %rsi,%rcx
call CLASSES$_$TBITS_$__$$_EQUALS$TBITS$$BOOLEAN
movb %al,%bl
jmp .Lj197
.p2align 4,,10
.p2align 3
.Lj196:
movq %rdi,%rdx
movq %rsi,%rcx
call SYSTEM$_$TOBJECT_$__$$_EQUALS$TOBJECT$$BOOLEAN
movb %al,%bl
.Lj197:
movb %bl,%al
...
After:
...
# Peephole Optimization: %rdx = %rdi; removed unnecessary instruction
(MovMov2MovNop 6b}
call fpc_do_is
# Peephole Optimization: Swapped test and mov instructions to improve
optimisation potential
movq %rdi,%rdx
# Peephole Optimization: Swapped test and mov instructions to improve
optimisation potential
movq %rsi,%rcx
testb %al,%al
# Peephole Optimization: Moved mov instruction common to both
branches to before jump
# Peephole Optimization: Moved mov instruction common to both
branches to before jump
# Peephole Optimization: Moved destination label ahead of common
instructions
je .Lj198
call CLASSES$_$TBITS_$__$$_EQUALS$TBITS$$BOOLEAN
movb %al,%bl
jmp .Lj197
.p2align 4,,10
.p2align 3
.Lj198:
call SYSTEM$_$TOBJECT_$__$$_EQUALS$TOBJECT$$BOOLEAN
movb %al,%bl
.Lj197:
movb %bl,%al
...
In the above example, the parameter configuration prior to the two
CALL instructions are identical, so it can move these to before the
branching jump.
However, some optimisations are not triggering because they expect a
jump or SETcc instruction to appear directly after a TEST
instruction, for example, and I can't just track the FLAGS register
because it has to check the condition that's being used too (e.g.
"MovAndTest2Test" requires the condition be C_E or C_NE).
There are a couple of solutions to this:
- Some instructions like those in the post-peephole stage could be
adapted to look ahead further for an appropriate instruction,
stopping if it finds one or if it finds another instruction that
modifies the flags. This will produce more complicated compiler code
though.
- Have a flag that tells the compiler to run pass 1 again after pass
2 (and have my common instruction optimisations in pass 2). This
would allow deeper optimisations but may cause significant slowdown
in the compiler, so I would only recommend this flag be honoured
under -O3 and -O4.
I'm trying to weigh the pros and cons of each, not least because in
some cases, my common instruction optimisations aren't as efficient
in pass 2 because other pass 1 optimisations ensure the instructions
either side of the branch are no longer identical.
Currently I'm seeing if I can avoid rerunning pass 1 and instead
improving the problematic optimisations to be more flexible with the
location of their SETcc and Jcc instructions.
Gareth aka. Kit
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
