[fpc-devel] Inlining problem and LEB128

[Jonas Maebe]

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
> collision.

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.


Jonas