This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Performance measurements (thanks and conclusion)
- To: martin dot kahlert at mchp dot siemens dot de
- Subject: Re: Performance measurements (thanks and conclusion)
- From: N8TM at aol dot com
- Date: Fri, 26 Jun 1998 09:05:38 EDT
- Cc: egcs at cygnus dot com
In a message dated 6/25/98 8:25:38 AM Pacific Daylight Time,
martin.kahlert@mchp.siemens.de writes:
> -Why is it so difficult for gcc to transform the code
> for(i=0;i<n;i++)
> result[i]=a[i]+2*a[i+1]+3*a[i+2];
>
> into something like
>
> _tmp0=a[0];_tmp1=a[1];_tmp2=a[2];
> for(i=0;i<n;i++)
> {
> result[i]=_tmp0+2*_tmp1+3*_tmp2;
> _tmp0=_tmp1;
> _tmp1=_tmp2;
> _tmp2=a[i+2];
> }
C code is often written with pointers which cannot be "disambiguated" to
resolve potential aliases (supposing that result[] overlaps a[]) except
possibly with a global analysis across all functions. Maybe this is why many
C compilers don't attempt such analysis even in the simple cases. I've seen
that even the best compilers don't do the analysis where the read and written
data come from different cross-sections of the same array.
Next, gcc has to deal with architectures where such a transformation can't be
implemented efficiently. A partial solution is to eliminate duplicate memory
references in an unrolled loop body, and I'd certainly like to see that happen
more reliably.