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

[Sergei Gorelkin]

Florian Klaempfl wrote:
> 
> Help me, why do we need dfa :)?

I am not sure that we need the particular DFA from optdfa.pas, but 
something to reduce conservativeness of escape analysis is definitely 
needed. Otherwise, temps that are needed for just one particular case of
x:=f(x) are being created almost everywhere.
DFA comes from Jonas's advice from one of the first messages:

> That's because the compiler only performs a context-insensitive
 > escape analysis (i.e., it is as conservative as possible: when you ask
> whether the address of a variable is taken, it will give an answer
> which is correct/safe regardless of which statements have already been
> executed).

> To reduce the conservativeness, you have to use DFA and record the
> individual state changes (or states) of all variables at all points
> where they may be needed.
--------------------

>> 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.
> 
If I understand right, it means that except block cannot be optimized, 
but inside the 'try' part normal rules still apply? E.g. in "a:=1" line, 
we know that "d" is not assigned yet?
If a variable is not referenced within except block, it may be treated 
as if except block does not exist?

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

Sergei