[fpc-devel] An optimizer bug?

[Jonas Maebe]

On 28 Dec 2007, at 15:16, Sergei Gorelkin wrote:

> I had isolated the issue, it is maybechangetemp() in ncgld.pas. If I  
> modify this function to always return false, the issue is gone.  
> Actually the failure is caused by incomplete deallocation of the  
> AnsiString temp variable - its initialization and finalization code  
> is not deleted.
>
> ...But what the hell is happening? First, at pass1 compiler does a  
> whole load of checks, decides that the assignment of function result  
> cannot be optimized, and allocates an intermediate temp. Then, at  
> pass2 (and with -O2 specified), it optimizes this assignment and  
> tries to delete the temp, based solely on the fact that the right  
> side of assignment is LOC_REFERENCE. All escape analysis from pass1  
> is void then?

maybechangetemp() predates the existence of the escape analysis. It's  
orthogonal to the function result optimization. It's simply that if  
you have

memloc1:=memloc2

then you can, under certain circumstances (and there's probably an  
incompatibility between the checks here and your changes -- keep in  
mind that checks/optimizations are often written with what the  
compiler can generate in mind, and not based on all possible code  
sequences that exist; that's also why the assembler optimizer is not  
run on user-written assembler), actually do something like

@memloc1:=@memloc2

(i.e., any further reference to memloc1 from then on will actually use  
memloc2 instead, regardless of whether memloc2 comes from a function  
result or from something else).

> How should this be fixed?

I don't know by heart, and I'll soon leave on holidays until January,  
1st, so I won't have time to check during the coming days (but it's  
possible that.


Jonas