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

[Jonas Maebe]

On 04 Dec 2007, at 11:30, Sergei Gorelkin wrote:

> Currently, when assigning types that need helper routines (records,  
> Windows widestrings and variants), the compiler converts assignment  
> into a helper call immediately. If this is moved from typecheckpass  
> to pass1, certain assignments get the chance to be optimized away.  
> See the patch attached.
>
> I had run the testsuite with the patch, the results were the same  
> as with unpatched compiler.
>
> This works, but the desired goal is achieved only partially.
> For example, in packages/base/netdb/uriparser.pp there are 4 cases  
> that may (and need to) be optimized:
> 1) In function ParseURI(const URI: String):  TURI; - assignment to  
> the function result;
> 2,3) In ResolveRelativeURI() - the first two statements:
>   Base := ParseUri(BaseUri);
>   Rel := ParseUri(RelUri);
>
> 4) In URIToFilename() - also the first statement:
>   U := ParseURI(Uri);
>
> Only the case 4 is optimized by the patch. In cases 2 and 3, I  
> guess that compiler assumes that address of Base and Rel is taken  
> (although actually it is taken much later).

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.

> In case 1, I don't know. Maybe someone can give me a hint how these  
> cases can be handled?

In case 1, I think it's because the function result itself is already  
basically a var-parameter passed to ParseURI and is treated like any  
other var parameter (i.e., a parameter which may also be accessible  
in another way, e.g. because a global variable was passed as var  
parameter). However, I guess the function result is a special case,  
since either
a) the address of a temp is passed, which is by definition not  
accessible from elsewhere (unless you write unsupported and broken code)
b) the address of a variable is passed, but this is only done if the  
escape analysis determines that this variable is not accessible from  
elsewhere

So I guess a special case for function results could be added.


Jonas