[fpc-devel] Optimizer Overhaul Take 2... Jump Optimizations

[J. Gareth Moreton]

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 <gareth at moreton-family.com 
> <mailto:gareth at 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 at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20191101/e74fe702/attachment.html>