Looks like we have a deal then! Break away code from "pass_1" into
"pass_semantic".
Thanks for your support Florian - I'll start making plans.
Gareth aka. Kit
On 14/07/2019 19:45, Florian Klämpfl wrote:
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton:
So having a long think over the past day, I'm starting to turn against the
second idea I had because it would require
complex state variable tracking and is just asking for a new bug to be
introduced, not to mention that the additional
overhead will probably offset any potential speed gains, so the cleaner, simple
solution sounds far more appealing now.
Also, when it comes to dead nodes (an except section that gets removed or any code
following "Exit" in the same block),
there's nothing to stop the compiler from deleting the nodes completely, since
semantics have already been checked (and
maybe chucking in an extra "unreachable code" warning if needs be), thus
pruning the tree and making the process faster
for pass_generate_code.
I do wonder why 'simplify' is a distinct method though, because a lot of the
time one can simply put its code at the end
of 'pass_1' and there wouldn't be any difference in functionality (plus what
counts as 'pass_1' and what counts as
'simplify' is often left to the programmer's discretion) while nodes that have
more complex simplification, like
taddnode, could use their own private methods. It might be something for me to
experiment with on the side.
The idea is to keep passes distinct. It makes maintainace easier. Besides this,
Simplify is made to be run multiply
times, pass_1 not.
So the node parsing overhaul, so far...
- pass_semantic
Yes.
- pass_transform (what was "pass_1")
I wouldn't change this in one patch. Step by step ...
- simplify (if not merged into the above)
- pass_generate_code (I won't touch this for now)
On another note, I do think pass_2 (pass_generate_code) could use some refactoring. I
don't like how "flowcontrol" is a
global variable. Though it's unlikely to happen, such a state variable not
being tied to a management object (e.g.
current_procinfo) prevents the compiler from being multi-threaded, at least for
that pass.
Gareth aka. Kit
P.S. Anyone got a better name for "pass_transform"?
pass_1 was for years, I wouldn't change it for the time being.
_______________________________________________
fpc-devel maillist - fpc-devel@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
