[fpc-devel] Inlining problem and LEB128

[J. Gareth Moreton]

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