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:[EMAIL PROTECTED]
p^.field1:=2;
r1:=f(r2); {1}
p:[EMAIL PROTECTED];
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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
