[fpc-devel] Peephole optimizer tai class change proposals

J. Gareth Moreton gareth at moreton-family.com
Sun Oct 3 23:32:28 CEST 2021

One drawback I've noticed is that there's no clean way to free the 
optinfo pointer when the tai object is destroyed, plus there's the 
danger of the pointer being used as a plain integer instead of pointing 
to an actual structure (conversely, the Tag property in components was 
often used to hold an object pointer, especially in the 32-bit days).  I 
would like to propose having a Boolean field named "OwnsOptInfo" that, 
if True, calls Dispose on optinfo's value in tai's destructor so we 
don't get memory leaks.

Gareth aka. Kit

On 03/10/2021 13:15, J. Gareth Moreton via fpc-devel wrote:
> That's useful to know - thanks Jonas.
> On 03/10/2021 13:10, Jonas Maebe via fpc-devel wrote:
>> On 03/10/2021 14:04, J. Gareth Moreton via fpc-devel wrote:
>>> I'm aware that the tai class declares an "optinfo" field, although I'm
>>> uncertain if this is safe to use or not given it's wrapped by an
>>> conditional define and is of type Pointer.
>> It's wrapped under {$ifndef NOOPT}, because it's intended for use by
>> assembler optimisers and when NOOPT is defined, no assembler optimisers
>> are included.
>> It's defined as pointer because it's a field of an abstract base class
>> in a unit that has no dependencies on target-specific units, and the
>> actual type could be different for different target architectures.
>> Its purpose is indeed to attach a pointer to a record with extra
>> information that is only collected/updated during the optimisation 
>> phase.
>> Jonas
>> _______________________________________________
>> 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.

More information about the fpc-devel mailing list