Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2025-01

Inlined functions from compiled units

7 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hairy Pixels

Is the compiler actually able to inline functions which are used from a unit? When a unit is used it’s compiled to a .o file and linked so the compiler doesn’t have access to the source code anymore and thus can’t inline I would think.

I write this because I’ve recently learned of link-time optimizations (LTO) from LLVM where modules are compiled to bitcode which can be linked together and inlined. It’s probably much slower than using precompiled .o files but good for release builds. Without that I don’t see how the compiler can inline any code called from units, which includes the whole RTL!

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Hairy Pixels

Hairy Pixels via fpc-pascal schrieb am
Fr., 24. Jan. 2025, 02:17:

Show quoted text 12 lines
Is the compiler actually able to inline functions which are used from a unit? When a unit is used it’s compiled to a .o file and linked so the compiler doesn’t have access to the source code anymore and thus can’t inline I would think. I write this because I’ve recently learned of link-time optimizations (LTO) from LLVM where modules are compiled to bitcode which can be linked together and inlined. It’s probably much slower than using precompiled .o files but good for release builds. Without that I don’t see how the compiler can inline any code called from units, which includes the whole RTL!

When a function has inlining enabled (either explicit with the inline directive or implicit through AutoInline optimization) then in addition to generating its code to the object file (for direct calls) the node tree is stored in the PPU. And this node tree is then used for inlining the function.

So the compiler correctly handles inlining of precompiled code. We're not stupid after all...

Regards,
Sven

Reply by email

Hairy Pixels
to Sven Barth

On Jan 24, 2025 at 2:01:09 PM, Sven Barth via fpc-pascal <

Show quoted text 8 lines
wrote: When a function has inlining enabled (either explicit with the inline directive or implicit through AutoInline optimization) then in addition to generating its code to the object file (for direct calls) the node tree is stored in the PPU. And this node tree is then used for inlining the function.

oh it’s in the PPU. Ok that makes sense. I guess that serves the same purpose as the LTO system in other compilers. I was curious if this was maybe something on the TOOD list or partially implemented. Thanks.

Regards,
Ryan Joseph

Reply by email

Marco van de Voort
to Hairy Pixels

Op 24-1-2025 om 09:58 schreef Hairy Pixels via fpc-pascal:

Show quoted text 11 lines
On Jan 24, 2025 at 2:01:09 PM, Sven Barth via fpc-pascal wrote: > When a function has inlining enabled (either explicit with the inline > directive or implicit through AutoInline optimization) then in > addition to generating its code to the object file (for direct calls) > the node tree is stored in the PPU. And this node tree is then used > for inlining the function. oh it’s in the PPU. Ok that makes sense. I guess that serves the same purpose as the LTO system in other compilers. I was curious if this was maybe something on the TOOD list or partially implemented. Thanks.

Slightly different. LTO afaik requires multiple compiles where the later build uses info from the earlier build.

The FPC implementation inlines if the unit-with-function-to-be-inlined  was compiled before the unit that references the inline function. That is within the /same/ (single) build, but also has as disadvantage afaik that if it is NOT like that, it won't be inlined.

Reply by email

Hairy Pixels
to Marco van de Voort

On Jan 24, 2025 at 5:46:40 PM, Marco van de Voort via fpc-pascal <

Show quoted text 10 lines
wrote: Slightly different. LTO afaik requires multiple compiles where the later build uses info from the earlier build. The FPC implementation inlines if the unit-with-function-to-be-inlined was compiled before the unit that references the inline function. That is within the /same/ (single) build, but also has as disadvantage afaik that if it is NOT like that, it won't be inlined.

I think that’s right. LTO is much slower too so there’s that. I think Jonas once said in the LLVM backend it was 15% faster because of aggressive inlining.

Regards,
Ryan Joseph

Reply by email

Hairy Pixels
to Hairy Pixels

Since I’m topic on inlines. FPC always inlines even with debug flags and makes certain files impossible to break on. Is there a way to disable that? I would expect inlining to be off so you can could debug. I don’t have -Si on either which suggests it must be on to inline but I don’t see that happening.

Regards,
Ryan Joseph

Reply by email

Marco van de Voort
to Hairy Pixels: On Jan 24, 2025 at 5:46:40 PM, Marco van de Voort via fpc-pascal < I think that’s…

Op 24-1-2025 om 13:10 schreef Hairy Pixels via fpc-pascal:

Show quoted text 9 lines
> > The FPC implementation inlines if the unit-with-function-to-be-inlined > was compiled before the unit that references the inline function. That > is within the /same/ (single) build, but also has as disadvantage afaik > that if it is NOT like that, it won't be inlined. I think that’s right. LTO is much slower too so there’s  that. I think Jonas once said in the LLVM backend it was 15% faster because of aggressive inlining.

Note that one strategy doesn't inhibit the other.

I in theory FPC could do the double build strategy to improve inlining performance further, but that would be a considerable feature of course. Both more mandatory inlining and resolving more complicated mutual inlining patterns.

Reply by email