[fpc-devel] Deeper problem with Internal Error 200309201

[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.

So the node parsing overhaul, so far...

- pass_semantic
- pass_transform (what was "pass_1")
- 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"?


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus