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

2019-08-03 Thread Blaise
On 03.08.2019 15:01, Sven Barth via fpc-devel wrote: 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... Leaving the issue of current_filepos for a moment, the change

[fpc-devel] Scoped VMTDefs

2019-08-03 Thread Blaise
Before the main course, I offer the attached refactorings for trecorddef.create_global_internal: 1) streamline insertions into the symtable; 2) avoid shadow-copying of the parameter "n", which is now const -- βþ # HG changeset patch # User Blaise # Date 1564833600 -10800 # Sat Aug 03

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

2019-08-03 Thread Sven Barth via fpc-devel
Am 02.08.2019 um 21:27 schrieb bla...@blaise.ru: On 02.08.2019 21:36, bla...@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?

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-08-03 Thread Michael Van Canneyt
On Sat, 3 Aug 2019, Ondrej Pokorny wrote: On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it.

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-08-03 Thread Ondrej Pokorny
On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it. That would be great. I have been waiting for