[fpc-devel] Peephole optimizer tai class change proposals

J. Gareth Moreton gareth at moreton-family.com
Sun Oct 17 16:24:21 CEST 2021


That's why I was discussing with Jonas in how to handle that, since 
currently tai objects don't have a clean way to free them themselves, 
and optinfo is an untyped Pointer.  However, Jonas suggested to have the 
extra info objects stored in a linked list, so the solution I have in my 
showcase is a linked list owned by the TAsmOptimizer object that frees 
everything when it's destroyed.  If an instruction is added or 
destroyed, the extra info objects associated with remain in the linked 
list, just not attached to anything.  True, there would be dangling 
pointers left in them, but they're solely for searching purposes and 
they generally aren't dereferenced.  You need a valid tai object to 
access the relevant extra info.

Granted, it would be cleaner to simply have the extra opt accessed 
through a new field in the tai declaration, and the constructor and 
destructor handle initialisation and cleanup.

Gareth aka. Kit

On 17/10/2021 15:00, Florian Klämpfl via fpc-devel wrote:
>
>> Am 11.10.2021 um 10:00 schrieb J. Gareth Moreton via fpc-devel <fpc-devel at lists.freepascal.org>:
>>
>> One for Jonas mainly, but also for Florian.  This is a new "extra optimisation information" feature that allows the peephole optimizer to leave 'notes' and other extra information on individual tai objects for later reference.  An initial showcase is to store a link to the destination label if it's not available in the lookup table (becuase it was created later by a peephole optimisation).
>>
>> https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/74/diffs
>>
>> Currently the showcase doesn't appear to show any additional optimisations in the x86-64 RTL because the jump optimisation that creates a new label is almost never called.
>>
>> I'll use this feature more extensively in the future, such as for storing information on the values of registers or making a note of a label that should be removed if possible because it would cause a long-term optimisation (something that a peephole optimisation that removes the label may not be able to determine because its own optimisation is questionable without that information).  See previous e-mails in this chain for an example.
> I fear a little bit that this extra info is messed up when instructions are added/removed.
>
> _______________________________________________
> 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



More information about the fpc-devel mailing list