I do hope we can find an acceptable proposal. I'm finding other
potential uses for such extra information that can't really be
replicated in the optimiser any other way, or it will take prohibitively
long to do so (e.g. on the order of O(n²)). For example, take this
assembly snippet:
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
> Am 11.10.2021 um 10:00 schrieb J. Gareth Moreton via fpc-devel
> :
>
> 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
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
Just made some more additions, this time introducing some fundamental
extra optimisation information classes that I can see myself using right
off the bat.
https://gitlab.com/CuriousKit/optimisations/-/compare/main...opt-info-list?from_project_id=29565238
I plan to use the tai one for
Would you approve something like this, Jonas? I admit it's not properly
tested yet, but I'm descending from TLinkedListItem (and the descendant
class can itself be descended from) and the TAOptObj class handles
allocation and cleanup of extra information. I'm not sure how practical
it is,
That seems fair - thanks for the advice Jonas. Now I just have to
decide where best to store this linked list of records. I'm sensing the
best place would be the TAsmOptimizer object that gets created and
released with each procedure that's optimised, if I remember correctly.
Gareth aka. Kit
On 03/10/2021 23:32, J. Gareth Moreton via fpc-devel wrote:
> One drawback I've noticed is that there's no clean way to free the
> optinfo pointer when the tai object is destroyed,
The best way to handle this is by allocating the optinfo's from a pool
(linked list of more or less arrays of
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
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
Hi everyone,
So as my optimisations get more and more sophisticated and intelligent,
I'm realising that I may need ways to store more information than is
currently possible. Obviously I want to avoid enlarging the internal
state too much or making the code unwieldly, but the additions I have
11 matches
Mail list logo
