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 mov rax,rdi in the caller function, even if rax is then never used.

{
26 begin
0x00000000004001c0 <+0>: push rbx

27 ut := TUtility.Create;
0x00000000004001c1 <+1>: movabs rsi,0x1
0x00000000004001cb <+11>: lea rdi,[rip+0x2b2fde] # 0x6b31b0 <VMT_$WTFINLINE_$$_TUTILITY>
0x00000000004001d2 <+18>: call 0x411b60
<SYSTEM$_$TOBJECT_$__$$_CREATE$$TOBJECT>
0x00000000004001d7 <+23>: mov rbx,rax

28 ut.dosomething;
0x00000000004001da <+26>: call 0x41bf20 <fpc_get_output> 0x00000000004001df <+31>: mov rdi,rax
0x00000000004001e2 <+34>: call 0x41c100 <fpc_writeln_end> 0x00000000004001e7 <+39>: call 0x416170 <fpc_iocheck> 0x00000000004001ec <+44>: mov rdi,rbx
0x00000000004001ef <+47>: mov rax,rdi
//<----------------------------------------------- here

29 ut.free;
0x00000000004001f2 <+50>: call 0x411cd0
<SYSTEM$_$TOBJECT_$__$$_FREE>

30 end;
0x00000000004001f7 <+55>: pop rbx
0x00000000004001f8 <+56>: ret
}

It is a popular pattern to add result := self; to _every_ method (or result := @self in objects/records), so it can be chained as dosomething().dosomething().dosomething(),.....
but one cannot use it with fpc efficiently, when it inserts too many unnecessary instructions

Best,

Benito

A strange statement.

This pattern is not inherently efficient. Why should it be ?

It's just something that boiled over from other languages and some people see it as a nifty way of writing code.

Michael.

Hi,

This pattern is not inherently efficient. Why should it be ?

It is not efficient, because of the pointless instruction!

Bye,
Benito

I am not speaking of the current FPC implementation. It may well be that the code is not most optimal.

I am asking, why do you think *this pattern* (of always returning self) should be inherently more efficient ?

Michael.

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

Isn't rax needed for the call to Free?

Well, a register-register move can be considered almost as a nop on modern architectures. If you really think it is important just provide a patch which eliminates such instructions.

The pattern definitely has its uses. E.g. in the user space of our operating system at work we have a StdOutPrinter class that is used like this:

=== code begin ===

StdIO::stdOutPrinter()->out("Helllo World ")->out(42)->out("
")->hex()->out(42)->line();

=== code end ===

Each function returns again the instance that was returned by StdIO::stdOutPrinter().

The whole pattern is called method chaining or fluent interface:
- https://en.wikipedia.org/wiki/Method_chaining
- https://en.wikipedia.org/wiki/Fluent_interface

Regards,
Sven

In our previous episode, Sven Barth via fpc-devel said:

No need to look so far, just look at TV/FV dialog construction.

I've never really worked with TV/FV, so I can't use that as an example ^^'

Regards,
Sven

E.g. KOL is based on this (or very close). The core methods always return self.

Call me old-fashioned, but I much prefer

   With StdIO::stdOutPrinter() do
     begin
     out("Helllo World ");
     out(42);
     out("");
     hex();
     out(42);
     line();
     end;

I see no point or gain in the "fluent" code.

Michael.

that

First C++ has no with-statement and second I definitely prefer my output to be on one line. :)
Also in other cases fluent interfaces are rather nice to have. Though they also don't force you to be used in that way :) (at least if they really only return Self/This).

Regards,
Sven

SomeProc(Builder
.Build('1')
.Build('2')

           .Build('3').Value);

    With StdIO::stdOutPrinter() do begin out("Helllo World ");out(42);out("");hex();out(42);line(); end;

;)

Also in other cases fluent interfaces are rather nice to have. Though they also don't force you to be used in that way :) (at least if they really only return Self/This).

I guess it is a matter of style.

Michael.

As far as I can see, that's not really different from the example Sven gave me ?

With builder do
   begin
   Build('1');
   Build('2');
   Build('3');
   SomeProc(Value);
   end;

Michael.

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.

Hi,,

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 instructions

Best,
Benito

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

Stefan Glienke wrote

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

On Tue, Aug 22, 2017 at 1:15 PM, Michael Van Canneyt <

This works well, but you can't tell the meaning of any single line, unless you're sure that all the methods are indeed defined in stdOutPrinter. Imagine

With StdIO::stdOutPrinter() do
    begin
    out("Helllo World ");
    out(size());
    ...
    end;

with size() belonging to the enclosing class. Someone adds size() to stdOutPrinter and you're toasted.

I've even seen a nested WITH misuse like

with src do begin
  with dst do begin
     name := firstName + ' ' + lastName;
     amount := ownAmount;
     ...
   end;
end;

which is a terrible and error-prone misuse.

I see no point or gain in the "fluent" code.

- It's as compact as WITH, but it's explicit.
- It can be written in a single line without violating convention.