[fpc-devel] Inlining problem and LEB128

[J. Gareth Moreton]

Ah, found it.  It was buried in the "noise" and me having a bit of a bad 
time mentally at the time.

https://bugs.freepascal.org/view.php?id=35346

The patches in that issue fix the inlined methods for 
compiler/cstreams.pas and compiler/entfile.pas so that "inline" appears 
in the interface section, as well as adding "inline" for methods that 
are short enough to warrant it (normally because their code only 
involves calling another method).

Gareth aka. Kit


On 24/06/2019 00:02, J. Gareth Moreton wrote:
> That's a point, true.  I've been for openness a lot lately, and one 
> doesn't normally distribute the PPU files with a closed-source 
> project, but I guess for those programs that need compiling on Linux 
> before they can be run, it's not very desirable if the PPU files 
> contain information on, say, a licence key algorithm.
>
> I did make some adjustments somewhere where I fixed the inlined 
> methods for the compiler and the RTL units so it at least honours 
> having "inline" in the interface section, but I'm not sure where I put 
> them.  Either way, currently changing the system to demand inline 
> appear in the interface section causes a heap of compilation errors.  
> Allowing "inline" to appear only in the implementation, but only 
> having a local effect, I haven't researched how to do that yet, but I 
> sense this is something that needs to be fixed eventualy.
>
> Gareth aka. Kit
>
> On 23/06/2019 15:06, Florian Klämpfl wrote:
>> 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
>>>> 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
>>> _______________________________________________
>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>> Not to forget that it would be very easy to reconstruct the source 
>> code from PPU. Some users might not like this ...
>>
>>
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>