From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10265 invoked by alias); 10 Dec 2007 21:00:16 -0000 Received: (qmail 10206 invoked by uid 22791); 10 Dec 2007 21:00:13 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.180) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Dec 2007 20:59:52 +0000 Received: by py-out-1112.google.com with SMTP id a29so5934004pyi for ; Mon, 10 Dec 2007 12:59:51 -0800 (PST) Received: by 10.65.115.4 with SMTP id s4mr14976831qbm.1197320389462; Mon, 10 Dec 2007 12:59:49 -0800 (PST) Received: by 10.64.91.5 with HTTP; Mon, 10 Dec 2007 12:59:49 -0800 (PST) Message-ID: <84fc9c000712101259p77416241y21cf54e12f3a9a0d@mail.gmail.com> Date: Mon, 10 Dec 2007 21:00:00 -0000 From: "Richard Guenther" To: "Kenneth Zadeck" Subject: Re: [lto] set alias info, poorly Cc: "Toon Moene" , "Jakub Jelinek" , gcc-patches@gcc.gnu.org, "Nathan Froyd" , "Mark Mitchell" , "Diego Novillo" In-Reply-To: <475DA662.6050700@naturalbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071206222919.GS14706@codesourcery.com> <84fc9c000712070247g6ac73f01m94e71acfdac039c1@mail.gmail.com> <20071207105948.GE13207@devserv.devel.redhat.com> <475D4552.6090306@naturalbridge.com> <475D9994.200@moene.indiv.nluug.nl> <475D9B19.8050808@naturalbridge.com> <84fc9c000712101209i471600f0v6f0533248b0cd3d5@mail.gmail.com> <475DA662.6050700@naturalbridge.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00485.txt.bz2 On Dec 10, 2007 9:49 PM, Kenneth Zadeck wrote: > > Richard Guenther wrote: > > On Dec 10, 2007 9:01 PM, Kenneth Zadeck wrote: > > > >> Toon Moene wrote: > >> > >>> Kenneth Zadeck wrote: > >>> > >>> > >>>> If you want to ask a question about two types, the first part of > >>>> that check will to see if the types come from the same front end. If > >>>> they do, then this issue can be resolved by asking some language > >>>> dependent code that will be located in the middle end of the compiler. > >>>> > >>> Well, that will mean that it'll be a fascinating piece of "language > >>> dependent code [...] located in the middle end of the compiler". > >>> > >>> The Fortran rules are basically: If you don't *tell* the compiler > >>> (hence the front end) that two items alias, they don't. > >>> > >>> I think this means that LTO *with* Fortran-sensible alias analysis > >>> will only work if the Fortran front end actually determines alias > >>> equivalence sets and passes that down to the middle end, which then > >>> (in this magically "language dependent code") has to do something > >>> intelligent with it ... > >>> > >> And then we will need to "merge" that info as we bring in the code for > >> other fortran modules. > >> i am not happy about going down this path, but the loss of that info is > >> not a good choice either. > >> > >> Consider the java case where two pointers cannot alias unless the type > >> of one pointer is derived from the other. This means that most pointers > >> do not alias rather than the c/c++ case where most pointers can possibly > >> alias. > >> > > > > The only maintainable way I see is to define middle-end rules (based on > > structural analysis) that are a conservative approximation of the union of > > the rules of all supported languages. Or punt with TBAA completely for > > LTO. > > > > Richard. > > > i think that you make a mistake to assume that just because type based > aliasing is mostly useless in c/c++, that it is useless in every > language. it is not. I believe that giving up on this will be a mistake. Well, I didn't suggest that this is the only way to go, but it is certainly the easiest one ;) Note that we can easily retain some basic TBAA for example for (arrays of) scalars without requiring to figure out the common subset that works for structural analysis. Also whole-program PTA should reduce the effects of TBAA even more, which I thought is one point why you want to have LTO. Richard.