Am 02.08.2019 um 21:27 schrieb
On 02.08.2019 21:36, 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.

fpc-devel maillist  -

Reply via email to