[fpc-devel] -O3 peephole proposal... run Pass 1 again if Pass 2 returns True

[J. Gareth Moreton]

Okay, so I ran a test and decided to see what would happen if I cycled 
back to pass 1 if pass 2 made changes.  Other than some edge cases in 
some packages (a bug caused an infinite loop at this stage of the make 
process), it causes no difference in code generation in the RTL.  The 
only notable difference is the compiler being much slower!

So I think we can write off this idea.  Granted, there are still some 
situations where pass 2 methods call pass 1 methods - the most notable 
one is a slightly convoluted optimisation in OptPass2MOV - if the 
instruction that follows is JMP, it calls OptPass2JMP on it right there 
and then, rather than wait for PeepHoleOptPass2Cpu to reach the 
instruction.  The reason for this is that many of OptPass2JMP's 
optimisations either insert a MOV that can be optimised with the 
original MOV, or inserts a RET and turns the original MOV into a 
deadstore.  However, this optimisation cannot be moved into pass 1 
without a drop in optimisation quality (notably, OptPass2JMP performs 
worse with converting blocks of MOV's into CMOVcc instructions).

Following on from comments from Florian in i38555, I'll see about 
factoring out the specific MOV/MOV and MOV/RET optimisations from 
OptPass1MOV at some point so they can be called separately.  Not only 
does it minimise problems and design violations of calling pass 1 
methods from pass 2, but it will also provide a speed gain in pass 2 
from not having to check everything that OptPass1MOV has to offer.

Gareth aka. Kit

On 28/02/2021 04:15, J. Gareth Moreton via fpc-devel wrote:
> Just as an example, when compiling the System unit on r48813, there 
> exists this block of disassembly:
>
> .Lj4072:
>     ...
>     leaq    (%rsi,%r13),%rax
>     leaq    -1(%rax),%r12
> # Peephole Optimization: SubMov2LeaSub
>     subq    $1,%rax
>     ...
>
> With my improvement over at i38555, the optimiser can remove the sub 
> instruction because %rax doesn't get used afterwards, hence:
>
> .Lj4072:
>     ...
>     jne    .Lj4070
>     leaq    (%rsi,%r13),%rax
> # Peephole Optimization: SubMov2Lea
>     leaq    -1(%rax),%r12
>     ...
>
> SubMov2Lea (and SubMov2LeaSub) is a Pass 2 optimisation because of the 
> potential to do deeper optimisations on the MOV instruction (which are 
> in Pass 1).  After the optimisation is made, and with the knowledge 
> that %rax's value is discarded afterwards, careful observation will 
> reveal that the two LEA instructions can be merged:
>
> .Lj4072:
>     ...
>     jne    .Lj4070
> # Peephole Optimization: SubMov2Lea
>     leaq    -1(%rsi,%r13),%r12
>     ...
>
> I've been working in a separate branch to improve the optimisations in 
> OptPass1LEA to detect this (it currently doesn't because the two 
> destination registers aren't identical), and this is why I call 
> OptPass1LEA from OptPass2SUB in the patch provided on i38555, although 
> as I originally described, this feels somewhat hacky and has a risk of 
> opening up more bugs.  A safer and more thorough approach, although 
> slower, would be to call Pass 1 again where the register tracking is 
> up to date, for example (when calling from OptPass2SUB, because the 
> first LEA is the previous instruction, the register tracking is ahead 
> by one instruction upon entering OptPass1LEA).
>
> Gareth aka. Kit
>
>
> On 28/02/2021 01:51, J. Gareth Moreton via fpc-devel wrote:
>> Hi everyone,
>>
>> I'm currently developing some new optimisations for Lea instructions 
>> after I discovered some new potential ones after fixing i38527.  That 
>> aside though, sometimes these optimisations only become apparent 
>> after Pass 2 has completed.  I've tried to change the order of things 
>> so the optimisation is made in Pass 1, but there's no easy 
>> combination that ensures the best optimisations take place (i.e. I 
>> make a change to improve one optimisation, and another one is made 
>> worse at the same time).
>>
>> I've taken to calling OptPass1XXX routines from OptPass2XXX routines 
>> in places where this is likely to happen, and so far this produces 
>> the best code - however, it feels hacky and problems may occur with 
>> register tracking if OptPass1XXX is called on a different instruction 
>> to the current one (e.g. one optimisation I've found requires calling 
>> GetLastInstruction and then calling OptPass1LEA on the result if it's 
>> a LEA instruction).
>>
>> So to help clean up the code and provide the best output, I would 
>> like to propose a cross-platform change to the peephole optimizer:
>>
>> - Under -O3, if a change was made in Pass 2 (implied if any of the 
>> OptPass2XXX routines return True), the peephole optimiser cycles back 
>> to Pass 1 and tries again.
>>
>> There are a few variants for this:
>>
>> - After Pass 1 is called after Pass 2, it then goes to the 
>> Post-peephole Pass regardless of if anything was changed.
>>
>> - It goes through the whole process again in that after Pass 1 is 
>> called again, Pass 2 is then called again, and if Pass 2 returns True 
>> again, then it goes back to Pass 1 and does it as many times as 
>> needed (or until it hits an upper limit to prevent an infinite loop 
>> due to a compiler bug).  Only once does Pass 2 return False that it 
>> goes to the Post-peephole Pass.
>>
>> - The third variant is that variant 1 is done for -O2 and variant 2 
>> is done for -O3 (and no extra run of Pass 1 for -O1).
>>
>> The obvious side-effect is that it causes the compiler to run 
>> slightly slower, but this could potentially be mitigated by merging 
>> the Pre-Peephole Pass with Pass 1, thus eliminating a distinct pass, 
>> while any missed optimisations that occur due to this are picked up 
>> in the second call to Pass 1 (it will most likely be picked up in the 
>> first call to Pass 1 due to PeepHoleOptPass1Cpu returning True and 
>> signalling another iteration).
>>
>> What are everyone's thoughts?
>>
>> Gareth aka. Kit
>>
>>
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus