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

[Jonas Maebe]

On 16 Dec 2007, at 11:13, Florian Klaempfl wrote:

> Jonas Maebe schrieb:
>>
>> On 16 Dec 2007, at 10:12, Florian Klaempfl wrote:
>>
>>> Sergei Gorelkin schrieb:
>>>>
>>>> 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.
>>
>> You need the latter to perform the former in a context-sensitive way.
>> Context-sensitive means that the outcome of your analysis is  
>> tailored to
>> a particular point in the procedure, rather than valid in any  
>> context/at
>> any point in the procedure.
>
> So indeed an alias analysis is required. Doing a simple one  
> shouldn't be
> too hard but I fear it will be too conservative as well ...

I read too quickly over your message, what I wanted to say was that  
your need dfa to perform *escape analysis* in a context-sensitive way.  
Alias analysis can be used to further refine the results (namely set  
the ti_addr_taken/addr_taken stuff in less cases, or replace them with  
another less global mechanism), but is not required.

>> No, it's the big if in tcallnode.maybe_create_funcret_node. The
>> conservative/context-insensitive parts are the ti_addr_taken and
>> addr_taken checks. These are computed globally for the entire current
>> procedure, rather than statement per statement based on which  
>> statements
>> can have been executed before the current statement is executed.
>
> What's a typical example of code which is compiled too conservative?

function f: trecord; forward;

procedure t(var r: trecord); forward;

procedure test;
var
   r: trecord;
begin
   r:=f; {1}
   t(r); {2}
end;

{1} cannot be optimized because the address of r is taken in {2}.


Alias analysis could moreover allow optimization of cases like this:

function f(const rec: trecord): trecord; forward;

procedure t(var r: trecord); forward;

procedure test;
var
   r1, r2: trecord;
   p: precord;
begin
   r2.field1:=3;
   p:=@r1
   p^.field1:=2;
   r1:=f(r2);   {1}
   p:=@r2;
   r1:=f(p^);   {2}
end;

{1} could be optimized because we would know that while p^ aliases r1,  
it has not escaped. {2} could be optimized because we would know that  
p aliases r2 and not r1.

There's of course also the issue of dynamic arrays, where you can have  
aliasing without taking the address of a variable (and in principle  
also with ansi/widestrings due to pchar/pwidechar casts which avoid  
the uniquestring calls).

> Maybe we can reduce the setting of ti_addr_taken?

Not without either alias analysis or compromising correctness in  
certain (valid) special cases.


Jonas