[fpc-pascal] inlining functions

Benito van der Zander benito at benibela.de
Thu Jan 3 00:10:23 CET 2019


Hi,

> procedure TStrBuilder.append(const s: RawByteString);
> begin
> append(pchar(pointer(s)), length(s)); //inlinetest.pas(24,3) Note: 
> Call to subroutine "procedure TStrBuilder.append(const p:PChar;const 
> l:Int64);" marked as inline is not inlined
> end; 

this seems to help

procedure TStrBuilder.append(const s: RawByteString);
var p: pchar;
begin
    p := pchar(pointer(s));
    append(p, length(s));
end;


> I would personally be in favour of removing all of the inlining hints, 
> because they are specific to a particular compiler version and mainly 
> cause people to waste time on premature optimisation (or on what they 
> think is an optimisation, but in many cases slows down things due to 
> increased instruction cache pressure). 

After updating from 3.1 to 3.3 I only have to look at around one 
thousand hints




The one-pass thing is probably the reason it now complains about all 
inline functions in dependency cycles, unit A uses unit B that uses unit 
A. Then unit A can't inline something unit B. Any way around that?



Best,
Benito

Am 02.01.19 um 00:41 schrieb Jonas Maebe:
> On 2019-01-02 00:19, Benito van der Zander wrote:
>
>> procedure TStrBuilder.append(const s: RawByteString);
>> begin
>> append(pchar(pointer(s)), length(s)); //inlinetest.pas(24,3) Note: 
>> Call to subroutine "procedure TStrBuilder.append(const p:PChar;const 
>> l:Int64);" marked as inline is not inlined
>> end;
>
> The compiler does not support inlining calls with parameters that cast 
> a managed type to an unmanaged type at this time.
>
> Regarding the reason why something cannot be inlined: sometimes you 
> can get more information with -vd, but not always (and even then the 
> reason may be vague).
>
> I would personally be in favour of removing all of the inlining hints, 
> because they are specific to a particular compiler version and mainly 
> cause people to waste time on premature optimisation (or on what they 
> think is an optimisation, but in many cases slows down things due to 
> increased instruction cache pressure). Especially in this case: there 
> is nothing potentially wrong with such a call, nor is the method in 
> general not inlinable, so there is no way to get rid of the hint other 
> than by removing the inline directive altogether (or by adding a 
> version of that routine with a different name that is not declared as 
> "inline"). This only promotes complicating code without any potential 
> improvement of productivity or clarity of the code/programmer intent.
>
>
> Jonas
> _______________________________________________
> fpc-pascal maillist  - fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20190103/72e0b30d/attachment.html>


More information about the fpc-pascal mailing list