[fpc-devel] Inlining problem and LEB128
florian at freepascal.org
Sun Jun 23 16:06:50 CEST 2019
Am 23. Juni 2019 16:05:05 schrieb Jonas Maebe <jonas at freepascal.org>:
> On 23/06/2019 01:10, J. Gareth Moreton wrote:
>> Currently, you can get away with specifying the "inline" directive for a
>> function in just the implementation section of a unit, and the function
>> will be inlined. However, in some situations, this can cause compiler
>> crashes which I believe is due to a mixture of the function no longer
>> being inlined and the internal CRCs not changing, possibly due to a
> While possible, I don't think the issue is CRC collisions. It's more
> likely to be stale pointers somewhere.
>> My solution to this is as follows... ALWAYS attempt to create a node
>> tree (unless "noinline" is specified). This is effectively
>> auto-inlining, but routines are not inlined unless the explicit
>> directive instructs the compiler to do so (or something like -O4 is
>> specified and the compiler determines that a function should be inlined
>> due to its shortness, say). This would help mitigate the problem of the
>> null node tree by causing the compiler to check said node tree and set
>> the "cannot inline" flag when appropriate.
>> This isn't ideal though, as it would have two notable side-effects:
>> - General compilation will be slightly slower because of extra analysis
>> on the node trees and copying them into the "inlined nodes" pointer.
>> - The compiled PPU files will increase in size significantly.
> The main issue is that loading PPUs would become a lot slower in this
> case: the entire node tree of all of those functions would then also be
> reconstructed while loading the PPUs -> tons of class instantiations.
> That would also significantly increase the compiler's memory usage.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
Not to forget that it would be very easy to reconstruct the source code from PPU. Some users might not like this ...
More information about the fpc-devel