[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