[fpc-devel] Deeper problem with Internal Error 200309201

[Florian Klämpfl]

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.