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
