Hi everyone,
So as my optimisations get more and more sophisticated and intelligent,
I'm realising that I may need ways to store more information than is
currently possible. Obviously I want to avoid enlarging the internal
state too much or making the code unwieldly, but the additions I have in
mind are for tai objects:
- A connected tai object
- A flags field or some kind of weighting field
The connected tai object would be useful for jumps that branch to labels
that were created during peephole optimisation, since these can't be
looked up with "getlabelwithsym" and so lose out on some subsequent
optimisations that look across jumps.
In regards to the weighting, a flag that indicates "desire to delete" or
something similar would be very useful in deciding if temporarily making
the code worse will have a larger payoff later on. Consider the
following code snippet (in the Classes unit under -O4 during some of my
personal experimentation):
...
movq %rdx,%rsi
movq %r8,%rdi
testq %r8,%r8
je .Lj2408
call CLASSES$_$TFPLIST_$__$$_COPYMOVE$TFPLIST
movq %rdi,%rdx
jmp .Lj2409
.p2align 4,,10
.p2align 3
.Lj2408:
movq %rsi,%rdx
.Lj2409:
movq %rbx,%rcx
call CLASSES$_$TFPLIST_$__$$_MERGEMOVE$TFPLIST
...
There's an option to insert "cmoveq %rsi,%rdx", mirroring the "movq
%rsi,%rdx" instruction (between the two labels), before "je .Lj2408",
and change that conditional branch to "je .Lj2409". By itself, this
wouldn't be a good optimisation because CMOV is slightly slower than MOV
and it would break the macrofusion betwen the TEST and JE instructions,
as well as increasing code size and overall instruction count. However,
it would cluster the two labels and .Lj2408 only has a single reference;
if it and the MOV instruction were removed, the entire block between
"jmp .Lj2409" and its label would collapse, erasing the original MOV,
and then a subsequent pass will notice that "cmoveq %rsi,%rdx" is
unnecessary because %rdx = %rsi already at that point in the program
flow, thus restoring the macrofusion. At this point, the optimal code
would be:
...
movq %rdx,%rsi
movq %r8,%rdi
testq %r8,%r8
je .Lj2409
call CLASSES$_$TFPLIST_$__$$_COPYMOVE$TFPLIST
movq %rdi,%rdx
.p2align 4,,10
.p2align 3
.Lj2409:
movq %rbx,%rcx
call CLASSES$_$TFPLIST_$__$$_MERGEMOVE$TFPLIST
...
Given that .Lj2409 only has a single reference from the nearby
conditional branch, it may be beneficial to remove the alignment hints
at this point too, although that one is more up in the air.
Nevertheless, if the peephole optimizer, while scanning the conditional
jump, sees that the destination label only has a single reference and
has been flagged 'desire to delete', it will be more likely to perform
the optimisation. However, if the flag is clear, it won't optimise. As
for when to set that flag, it will probably be when the peephole
optimizer scans the original "jmp .Lj2409" instruction and sees how
close it is to being a zero distance jump, with only alignment fields,
another label and a single MOV before it finds .Lj2409.
I'm aware that the tai class declares an "optinfo" field, although I'm
uncertain if this is safe to use or not given it's wrapped by an
conditional define and is of type Pointer. I could use optinfo to store
a reference to the tai_label object in a jump instruction - would this
be an acceptable use of it? I'm not sure about using it for a 'desire
to delete' flag though, especially where there might be situations where
other tai objects could carry it... maybe even a jump instruction.
This is more of a running commentary of my design thoughts, so I
apologise for the info dump, but to summarise, could I add a 'connected
object' and 'flags' field to the tai class, and/or can I use the optinfo
field for a similar purpose?
Remember I can always refactor later if a feature could be cleaned up or
restructured in some way.
Gareth aka. Kit
--
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
