Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-11

Request to remove "movzwl %ax, %eax" -> "andl $0xffff, %ax" optimisations

4 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

J. Gareth Moreton

Hi everyone,

Specifically to Florian, Jonas and Pierre, I would like to remove the "movz-> and" family of optimisations from the x86 peephole optimiser because the zero-extension commands no longer have the performance penalty that they had back in the 90s.  Both instructions have a read/write dependency, but movzx uses fewer bytes.

On a side-note, I'm exploring OptPass1Movx a bit more closely and found that you can't set Result to True on some of the optimisations (to indicate a change and to re-run Pass 1 under -O3) because they cause an infinite loop if you do (I've been researching ways to cut down on passes and speed up the peephole optimiser).  Additionally, there's also a problem that the optimisations in question sometimes end up 'fighting' with an optimisation in OptPass1MOV that does the opposite.  Either way it makes this part of the codebase somewhat fragile as well as wasting compilation time.

Gareth aka. Kit

Reply by email

Sven Barth
to J. Gareth Moreton

J. Gareth Moreton schrieb am Mi., 27. Nov.
2019, 18:08:

Show quoted text 8 lines
Hi everyone, Specifically to Florian, Jonas and Pierre, I would like to remove the "movz-> and" family of optimisations from the x86 peephole optimiser because the zero-extension commands no longer have the performance penalty that they had back in the 90s. Both instructions have a read/write dependency, but movzx uses fewer bytes.

In my opinion that should depend on the selected optimization processor (-OpX) as one might still want generate code for older processors.

Regards,
Sven

Reply by email

J. Gareth Moreton
to Sven Barth

That's a point.  Thanks Sven.

There's still some cleaning up to do though because of two families of optimisations fighting each other and a specific construct that is dangerously close to causing an infinite loop (the only reason why it doesn't is because it doesn't set Result to True to signal another iteration of Pass 1 under -O3).

Gareth aka. Kit

Sven Barth wrote 23 lines
J. Gareth Moreton < > schrieb am Mi., 27. Nov. 2019, 18:08: Hi everyone, Specifically to Florian, Jonas and Pierre, I would like to remove the "movz-> and" family of optimisations from the x86 peephole optimiser because the zero-extension commands no longer have the performance penalty that they had back in the 90s.  Both instructions have a read/write dependency, but movzx uses fewer bytes. In my opinion that should depend on the selected optimization processor (-OpX) as one might still want generate code for older processors. Regards, Sven _______________________________________________ fpc-devel maillist - https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

J. Gareth Moreton
to J. Gareth Moreton

This one is a case of inefficiency - this sequence of instructions appears in the compilation of the HexToBin function in the Classes unit (-O3, but with the peephole optimizer turned off):

    ...
    movzbw    (%rcx),%r9w
    andw    $15,%r9w
    movswl    %r9w,%r9d
    movl    %r9d,%ebx
    ...

When the peephole optimizer is turned on and the compiler has DEBUG_AOPTOBJ defined:

    ...
# Peephole Optimization: var15
# Peephole Optimization: var15
# Peephole Optimization: var15
# Peephole Optimization: var15
    movzbw    (%rcx),%r9w
    andw    $15,%r9w
    movswl    %r9w,%r9d
    movl    %r9d,%ebx
    ...

"var15" is the optimisation (also one of the risky infinite loop ones) that analyses a "movzbw/andw" pair and changes the "andw #, %regw" instruction to "andw (# and $FF), %regw".  It performs this optimisation during all four iterations of Pass 1, even though 15 and $FF = 15 in this case and nothing actually changes. Meanwhile, though unrelated, there appears to be no peephole optimisation to change "movswl %r9w,%r9d; movl %r9d,%ebx" to "movswl %r9w,%ebx".  Theoretically, in this instance, the use of R9 can be dropped completely and only RBX used, but that's another story.

I'm still looking at ways to improve the peephole optimizer, specifically reducing the number of passes where possible, but I figure I need to work on one function at a time.  OptPass1MOV and its sister functions could use a lot of refactoring.  I'll submit small patches over time that are easier to verify.

Gareth aka. Kit

Reply by email