[fpc-devel] Deeper problem with Internal Error 200309201

[Sven Barth]

Am 13.07.2019 um 14:12 schrieb J. Gareth Moreton:
> I would like some discussion on this with the administrative team 
> because this does require some careful design if we're going to do 
> this properly.  Building on Florian's suggestion, I would like to 
> propose splitting "pass_1" into "pass_syntax" and a pass that 
> transforms the nodes (I would name it "pass_transform", but this 
> doesn't sound 'important' enough, given it is effectively compiling 
> the nodes).  "pass_syntax" would be a public method declared in tnode 
> as the following "function pass_syntax: Boolean; virtual;" - if it 
> returns True, then everything was fine; if not, it returns False and 
> this can be used to set the error flag.  By being defined this way, 
> this is no ability for the node to transform itself, but it can set 
> private fields based on the syntax it finds (by setting private 
> fields, the "first pass" won't have to repeat some of the work needed 
> to determine how to transform the nodes).

"pass_syntax" is not a good name, because it does *not* do syntax 
checking (that was done by the parser). Instead it checks the semantic, 
so "pass_semantic" would be a more correct name.

Also I don't think a Boolean result is needed. Take a look at 
tgotonode.pass_1 which is after all the one which would need to be moved 
to pass_semantic: it uses CGMessage*() to write its messages (as all 
nodes do) which in turn sets the codegenerror flag if it wasn't set 
already. So after a call to a node's pass_semantic method all that needs 
to be checked is codegenerror to decide how to proceed further. Thus the 
semantic pass could simply be "procedure pass_semantic;virtual;".

> On the surface, the first implementation suggestion feels like the 
> cleaner option, but I don't know how much of a penalty it will add to 
> the compiler. Personally I would like to attempt a design for the 
> second implementation to keep the number of passes down to a minimum 
> and the compiler reasonably fast (also my motivation behind the x86_64 
> peephole optimizer overhaul).  But that's just my opinion.

In my opinion a clean, easily maintainable solution is preferrable.

> On an additional note, I do wonder if it's possible to merge "pass_1" 
> and "simplify", since they are treated pretty much identically in the 
> "firstpass" routine - if either of them return something other than 
> nil, it is considered to be a node transformation, running this block 
> of code (there are two copies, one for each call):
>
> p.free;
> p := hp;
> firstpass(p);
>
> (hp contains the return value of whatever method was just called) This 
> may be impractical because "simplify" is called elsewhere for some nodes.
>

I don't think combining the two passes is necessary. The ideas behind 
the two passes are after all different.

Regards,
Sven