Turns out it wasn't a bug, but a very contrived set-up.
When the peephole optimiser is turned off completely, the following is
revealed:
je .Lj371
jmp .Lj372
.Lj371:
movl $3,%r14d
movl $1,%r15d
jmp .Lj373
.p2align 4,,10
.p2align 3
.Lj372:
jmp .Lj333
.Lj373:
.Lj370:
.Lj367:
...
What happens is that the optimiser changes "je .Lj371; jmp .Lj372;
.Lj371:" into "jne .Lj372" (what I call a 'conditional jump inversion'),
and then the final destination is tracked: the compiler notices that
after "jne .Lj372", the program flow immediately stumbles upon an
unconditional jump ("jmp .Lj333"), so it changes the destination to
match, thus it becomes "jne .Lj333". After all of this, .Lj372 becomes
a dead label, and when the optimiser reaches "jmp .Lj373", it removes
all the dead code between it and the next live label, since it will
never be executed; this includes the original "jmp .Lj333" instruction
because .Lj372 is no longer referenced by anything (Then "jmp .Lj373" is
removed as well because the destination label is right after it once
everything is stripped). As such, because .Lj372 is a dead label and
there are no other (live) labels in that cluster, it correctly removes
the alignment fields... in other words, the remaining labels were never
actually aligned - it was just a coincidence they became aligned before.
Gareth aka. Kit
On 01/11/2019 14:11, Sven Barth via fpc-devel wrote:
J. Gareth Moreton <gar...@moreton-family.com
<mailto:gar...@moreton-family.com>> schrieb am Fr., 1. Nov. 2019, 12:56:
So the tests all passed on i386-win32 and x86_64-win64, so that's s a
good sign. I can't submit the patches for evaluation yet because I
haven't finished the design spec yet, and also because of a minor bug
that deals with collapsing label clusters:
.p2align 4,,10
.p2align 3
.Lj370:
.Lj367:
.Lj364:
.Lj361:
.Lj358:
.Lj355:
.Lj352:
.Lj349:
.Lj346:
.Lj343:
.Lj340:
In this segment, everything is stripped except for the last label,
which
is fine as all the references are changed too. Unfortunately, the
alignment fields are removed too, which shouldn't happen. It doesn't
produce incorrect code, but it may incur a performance penalty, so
shouldn't be removed - I'm just trying to figure out why that's
happening!
Considering that you said that this feature is essentially cross
platform: on some other platform the alignments might be important
beside performance (e.g. a branch inside a branch delay slot or
something like that). So, yeah, that should be fixed...
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
