r18252 - x*x -> sqr(x) optimization (Was: Re: [fpc-devel] ARM native compilation (Toshiba AC100))

Thomas Schatzl tom_at_work at gmx.at
Fri Sep 23 12:17:35 CEST 2011


 Hi,

 On Fri, 23 Sep 2011 10:52:17 +0200, Jonas Maebe wrote:
> On 23 Sep 2011, at 01:21, Thomas Schatzl wrote:
>
>> I found that 18251 is okay, but the newer ones are not when  
>> compiling with -O2. It seems that one optimization that transforms  
>> expressions of type x*x into sqr(x) for floats in 18252 (and 18257  
>> and 18263 that seem to have been fixing issues with the original  
>> implementation) causes troubles. With that in place, a compiler  cycle 
>> hangs at ppc2 compiling something (processing real2str.inc  from the 
>> system unit fyi).
>>
>> Florian, Jonas, any ideas? Seems to be related to softfloat code  
>> generation because apparently other platforms are fine.
>
> The optimization changes x*x into sqr(x). For ARM/softfloat, the
> compiler calls the fpc_sqr_real() helper from the RTL.
>
> The code of this helper is:
>
>     function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;{$ifdef
> MATHINLINE}inline;{$endif}
>     begin
>       result := d*d;
>     end;
>
> So yes, this clearly puts the compiler into an endless loop. I'm not
> sure what would be a clean fix for this (other than completely

 Other options I see:
 - disable if using softfloat knowing that the soft float code just 
 transforms this into the same code sequence again
 - move it to i386 specific optimizations since afaik it is the only 
 arch which has an instruction which benefits from that.

> disabling the transformation; does it improve the generated code that
> much beyond what CSE can achieve?)

 I doubt it has any noticeable impact.

 Thomas




More information about the fpc-devel mailing list