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

Florian Klaempfl florian at freepascal.org
Sun Dec 16 10:12:02 CET 2007


Sergei Gorelkin schrieb:
> 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:

When Jonas posted this message first, I didn't understand because I
thought I read it too quick, but after carefull reading, I still don't
understand it :) The first paragraph talks about alias analysis while
the second talks about dfa.

Let it consider from a practical point :) Which piece of code makes too
conservative assumptions? The big if in ncgld.maybechangetemp?

> 
>> 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
> 
> 
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 




More information about the fpc-devel mailing list