Re: Inlining with gcc 4.x.x (Linux) ?

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.

-- 
                              Waldek Hebisch

_______________________________________________
Gpc mailing list
[email protected]
https://www.g-n-u.de/mailman/listinfo/gpc