[fpc-devel] Recent changes to x86-64 peephole optimisation

[J. Gareth Moreton]

Hi Florian,

Thanks for the response.  I'm mostly referring to r44241 that introdues 
GetNextInstructionUsingRegTrackingUse and some restrictions on more 
expensive optimisations.

One thing I wanted to bring up is "RemoveCurrentP(p)" - I've been 
avoiding its use because it calls GetNextInstruction, which can be an 
expensive call, and a lot of the time, I already know what the next 
instruction is at that point (hence the "p := hp1;" assignments that 
appear after it).  I figure it might class as a micro-optimisation 
though and I can certainly see a call to "RemoveCurrentP(p)" being 
safer, lest we accidentally leave p dangling.  Can I recommend we split 
this into two separate commands named "RemovePAndSetNext" and 
"RemovePAndNil" or some such?  The former would set p to 
GetNextInstruction, while the latter would set p to nil.  With the aid 
of inlining and deadstore removal, if "p := hp1;" follows a call to 
RemovePAndNil(p), then the setting of p to nil will be removed by the 
optimiser.

Gareth aka. Kit

On 09/03/2020 16:06, Florian Klaempfl wrote:
> Am 08.03.2020 um 15:54 schrieb J. Gareth Moreton:
>> Hi everyone,
>>
>> I've been away for a few days so I haven't
>> been paying too much attention to the trunk,
>> but I've noticed some new changes to the x86-
>> 64 peephole optimized that look interesting.
>> Can someone fill me in on what they're meant
>> to do and the motivation behind the
>> additions? This is just so I fully understand
>> what everything is doing and don't
>> accidentally overwrite something.
>>
>
> Which ones do you mean? Normally, I try to a add a reasonable commit 
> message.
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>

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