[fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

[Sven Barth]

Am 02.08.2019 um 21:27 schrieb Blaise at blaise.ru:
> On 02.08.2019 21:36, Blaise at blaise.ru wrote:
>> embed a copy of the body of insert_struct_hidden_paras into 
>> TVMTBuilder.generate_vmt, then merge those two procdef-member 
>> traversals into one (hey, performance!)
>
> Would you guys oppose such a change? Then we could rename 
> insert_struct_hidden_paras back to insert_record_hidden_paras :)

In principle one could do that, though more often than not inside the 
compiler maintainability beats performance. I'd prefer an opinion of 
Florian and/or Jonas on this though...

> Aside from performance, I would like it for closures (for their 
> nameless methods, the insertion of hidden parameters cannot be 
> deferred until the VMT generation).

What difference would it make for closures? In the end you'd still need 
to ensure that handle_calling_convention isn't called twice.

> Also, handle_calling_convention would need to be changed not to 
> indirectly rely on current_filepos, but I see that as a bonus: the 
> trick of swapping current_filepos could be removed from its callers 
> (namely, insert_record_hidden_paras).

That would mean that the functions called inside 
handle_calling_convention (mainly those inside the if-clause for 
hcc_insert_hidden_paras) would have to be adjusted to handle that as 
well (especially lovely for those invoked by ForEachCall).
If this is done there should also be an overload of 
handle_calling_convention that does not take a tfileposinfo argument and 
instead passes on current_filepos so that those code parts that just 
want to use the current position don't need to be changed.

Regards,
Sven