From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10839 invoked by alias); 6 Jan 2008 10:08:43 -0000 Received: (qmail 10603 invoked by uid 48); 6 Jan 2008 10:07:59 -0000 Date: Sun, 06 Jan 2008 10:35:00 -0000 Message-ID: <20080106100759.10602.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00481.txt.bz2 ------- 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 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 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