------- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-06 10:07 -------
Note that this shouldn't really be affected by strict aliasing or not. Note
that the FE generated IL causes the first alias pass to emit too conservative
alias info as well:
# VUSE <MPT.5965_208230>
D.6049_4652 = atmp.1110.data;
D.6050_4653 = (complex(kind=4)[0:] *) D.6049_4652;
D.6051_4654 = S.1113_289 + D.3340_4634;
# VUSE <SFT.......>
D.6052_4655 = (*D.6050_4653)[D.6051_4654];
I suppose the atmp.1110.data type is something like (void *), so the
cast is required. But this really pessimizes the middle-end IL and
it looks like the FE knows it will be complex(kind=4)[4] at the point
of creation. Note fixing this will also improve optimization and thus
runtime performance.
I also see the FE creates lots of array temporaries:
struct array2_complex(kind=4) atmp.1093;
complex(kind=4) A.1094[4];
struct array2_complex(kind=4) atmp.1095;
complex(kind=4) A.1096[4];
struct array2_complex(kind=4) atmp.1100;
complex(kind=4) A.1101[4];
struct array2_complex(kind=4) atmp.1102;
complex(kind=4) A.1103[4];
struct array2_complex(kind=4) atmp.1106;
complex(kind=4) A.1107[4];
real(kind=4) D.3326;
...
instead of re-using a single one. This also causes internal representation
to blow up.
So, to sum up, the situation could be significantly improved by improving
the FE. (Like I noticed for I/O statements, where I provided a patch -
that was not accepted - to share temporary variables created for the I/O
context)
As we already have bugs for the middle-end partitioning problems, I make
this one a Fortran FE bug instead.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |33974
Component|tree-optimization |fortran
Summary|compile-time problem with - |Fortran FE generated IL
|fstrict-aliasing |pessimizes middle-end IL and
| |analysis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
