peter wrote:
I've built GPC 3.4.6 and 4.3.6 on Debian Stretch (64bit) Running benchmarks on a Perlin Noise routine I get
3.4.6 5.6 secs 4.3.6 11.0 secs !!
The difference seems to be mainly down to a failure of 4.3.6 to inline.
<snip>
Maybe I have broken my build of 4.3.6 Can anyone else conform the status of inlining on linux x86 with 4.x.x compilers? The simple example from the info file
program InlineDemo;
function Max (x, y: Integer): Integer; attribute (inline); begin if x > y then Max := x else Max := y end;begin WriteLn (Max (42, 17), ' ', Max (-4, -2)) end.
Also does not work for me with 4.3.6. It still produces a call instruction. call _p__M0_S0_Max
From further tinkering around, I notice that 3.4.6 often inlines even
when not asked to do so, whereas 4.3.6 very rarely if ever inlines. Neither compiler seems to obey the inline attribute!
Anyone any thoughts on this? Hoping of course that its an easy to fix typo type bug...
I will look into this. One thing to remember is that gcc backend treat 'inline' only as a hint and apparently with newer backend gcc developers claim that compiler knows better then the programmer if inlining is good. There is a way to request inlining regardless of compiler opinion about benefits, but this still may fail because compiler can inline only when certain problematic constructs are avoided. For example nonlocal gotos disable inlining, even though for such routines inlining could be very profitable by converting nonlocal jumps to local ones. Also I am affraid that gpc currently does not implement needed directive.
If you use subranges or arrays you can try to disable range checking. Gcc backend is quite good at removing redundant checks, but due to checking code routines may appear bigger and inliner may decide that inlining is too costly.