[fpc-devel] (patch) An attempt to improve assignments/functionresult reuse

Florian Klaempfl florian at freepascal.org
Sat Dec 15 21:23:09 CET 2007


Sergei Gorelkin schrieb:
> Sergei Gorelkin wrote:
>> Florian Klaempfl wrote:
>>>
>>> Ok, so I guess we can change this. Anybody volunteer to implement it :)?
>>
>> Well, if there is no hard time schedule imposed on this, I can try.
>> I've started all this, after all :)
>>
> I had investigated the issue. Surprisingly enough, changing string
> return convention does not cause any test failures on both Linux and
> Windows. The only issue is that statements like 's := Copy(s, ...)'
> start leaking memory, but that is easily fixed.
> 
> However, it seems that I understood reasons for the current
> implementation. It is exactly the same reason for which I've started
> this topic - until assignments of function return value can be properly
> optimized, the current implementation is more effective than Delphi's.
> Changing the convention right now will replace implicit exception frame
> in callee by a temp variable (with the same implicit frame) in caller,
> resulting in no performance increase at best.
> 
> So I guess that I should turn straight to DFA. However, some questions
> arise even before the start:

Help me, why do we need dfa :)?

> 
> 1. I see no place in compiler source where cs_opt_nodedfa flag is being
> set. How is it supposed to work?

It is only set together with -O2

> 
> 2. DFA is currently disabled for functions with exception frames, which
> makes it useless for resolving the issue with automated types
> assignments. Any hints how to work around this?

Well, when having exception frames, dfa gets rather useless:

try
  a:=1;
  b:=c;
  d:=e;
  ...
except/finally
  ...
end;

when entering the except block, all variables being assigned in the try
block live because from every instruction in the try block a execution
path goes to the except/finally block.

But turning it on and creating one is no real problem, it only pretty
useless ;)



More information about the fpc-devel mailing list