Re: [fpc-devel] Optimizing unused return values of inline functions

Hi, Isn't rax needed for the call to Free? I think self stays in rdi Perhaps we need a new calling convention that keeps self in rax. Or the return value in rdi Cheers, Benito Am 21.08.2017 um 15:45 schrieb Stefan Glienke: Isn't rax needed for the call to Free?

Re: [fpc-devel] Optimizing unused return values of inline functions

Hi,, SomeProc(Builder .Build('1') .Build('2') .Build('3').Value); That's exactly what I wanted to use it for And since a string builder is such a low level construct, mostly used for performance improvements, it needs to be fast without additional

Re: [fpc-devel] Optimizing unused return values of inline functions

Often a fluent API has some grammar described via different interfaces that are implemented by either one (in this case you always return Self) or different classes. It is not just to chain methods together that you could also write like you did. > On 22 August 2017 at 13:15 Michael Van

Re: [fpc-devel] Optimizing unused return values of inline functions

On Tue, 22 Aug 2017, Kazantsev Alexey via fpc-devel wrote: On Tue, 22 Aug 2017 13:15:24 +0200 (CEST) Michael Van Canneyt wrote: Call me old-fashioned, but I much prefer With StdIO::stdOutPrinter() do begin out("Helllo World "); out(42);

Re: [fpc-devel] Optimizing unused return values of inline functions

On Tue, 22 Aug 2017 13:15:24 +0200 (CEST) Michael Van Canneyt wrote: > Call me old-fashioned, but I much prefer > >With StdIO::stdOutPrinter() do > begin > out("Helllo World "); > out(42); > out(""); > hex(); > out(42); > line(); >

Re: [fpc-devel] Optimizing unused return values of inline functions

Am 22.08.2017 13:15 schrieb "Michael Van Canneyt" : > > > > On Tue, 22 Aug 2017, Thaddy de Koning wrote: > >>> On 21.08.2017 13:22, Michael Van Canneyt wrote: On Mon, 21 Aug 2017, Benito van der Zander wrote: > Hi, > >> This pattern is

Re: [fpc-devel] Optimizing unused return values of inline functions

On Tue, 22 Aug 2017, Thaddy de Koning wrote: On 21.08.2017 13:22, Michael Van Canneyt wrote: On Mon, 21 Aug 2017, Benito van der Zander wrote: Hi, This pattern is not inherently efficient. Why should it be ? It is not efficient, because of the pointless instruction! I am not

Re: [fpc-devel] Optimizing unused return values of inline functions

> On 21.08.2017 13:22, Michael Van Canneyt wrote: >> >> >> On Mon, 21 Aug 2017, Benito van der Zander wrote: >> >>> Hi, >>> This pattern is not inherently efficient. Why should it be ? >>> >>> >>> It is not efficient, because of the pointless instruction! >> >> I am not speaking of the

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 21:15, Marco van de Voort wrote: > In our previous episode, Sven Barth via fpc-devel said: >>> I am asking, why do you think *this pattern* (of always returning self) >>> should be inherently more efficient ? >> >> The pattern definitely has its uses. E.g. in the user space of our >>

Re: [fpc-devel] Optimizing unused return values of inline functions

In our previous episode, Sven Barth via fpc-devel said: > > I am asking, why do you think *this pattern* (of always returning self) > > should be inherently more efficient ? > > The pattern definitely has its uses. E.g. in the user space of our > operating system at work we have a StdOutPrinter

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 13:22, Michael Van Canneyt wrote: > > > On Mon, 21 Aug 2017, Benito van der Zander wrote: > >> Hi, >> >>> This pattern is not inherently efficient. Why should it be ? >> >> >> It is not efficient, because of the pointless instruction! > > I am not speaking of the current FPC

Re: [fpc-devel] Optimizing unused return values of inline functions

Am 21.08.2017 um 12:12 schrieb Benito van der Zander: > Hi, > >> This pattern is not inherently efficient. Why should it be ? > > > It is not efficient, because of the pointless instruction! Well, a register-register move can be considered almost as a nop on modern architectures. If you

Re: [fpc-devel] Optimizing unused return values of inline functions

Isn't rax needed for the call to Free? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 13:22, Michael Van Canneyt wrote: I am asking, why do you think *this pattern* (of always returning self) should be inherently more efficient ? Benito didn't state it is more efficient (than something else). He said it is popular and not optimized in fpc. Ondrej

Re: [fpc-devel] Optimizing unused return values of inline functions

On Mon, 21 Aug 2017, Benito van der Zander wrote: Hi, This pattern is not inherently efficient. Why should it be ? It is not efficient, because of the pointless instruction! I am not speaking of the current FPC implementation. It may well be that the code is not most optimal. I am

Re: [fpc-devel] Optimizing unused return values of inline functions

Hi, This pattern is not inherently efficient. Why should it be ? It is not efficient, because of the pointless instruction! Bye, Benito Am 21.08.2017 um 08:39 schrieb Michael Van Canneyt: On Sun, 20 Aug 2017, Benito van der Zander wrote: Hi, why does fpc not remove the

Re: [fpc-devel] Optimizing unused return values of inline functions

On Sun, 20 Aug 2017, Benito van der Zander wrote: Hi, why does fpc not remove the calculation of the return value of inline functions, when the return value is unused? For example type TUtility = class function doSomething: TUtility; inline; end; It is a popular pattern to add result

[fpc-devel] Optimizing unused return values of inline functions

Hi, why does fpc not remove the calculation of the return value of inline functions, when the return value is unused? For example type TUtility = class function doSomething: TUtility; inline; end; function TUtility.dosomething: TUtility; begin writeln(); result := self; end; adds a