The field sharing refers to this:
"What I mean is that if a function is marked as "pure" or "inline" (or
both), only one copy of the unoptimised node tree is stored in the
"inlininginfo" field, and both "pass1_pure" and "pass1_inline" duplicate
this tree and transform it as needed. Because only the unoptimised tree
is stored, I felt there was no need to store this twice (doing so would
also increase the size of PPU files)."
This copy of the tree is stored for inline functions before the first
pass is executed. Pure functions copy and analyse the same tree. If a
function is both pure and inline, these initial trees will always be
identical, so it is redundant to store two copies.
Kit
On 16/12/2022 06:44, Sven Barth wrote:
Am 16.12.2022 um 02:02 schrieb J. Gareth Moreton via fpc-devel:
The purity analysis process is very dependent on the node tree being
as clean as possible, and so depends on a fair few merge requests
that have not yet been approved. I'm guessing Florian and Jonas and
others are somewhat busy, what with being December and all.
- https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/232 -
strips unnecessary typeconv nodes (this helps a lot with constant
propagation).
- https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/342 -
strips excess nothing nodes.
I didn't say that you shouldn't clean up the tree for your purity
analysis (that sounds so wrong :P ), I simply asked what you meant
with “share the same field” and if it is what I think it is then it's
a bad idea and you shouldn't “share the same field” but introduce your
own.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
