From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2791 invoked by alias); 10 Dec 2007 20:49:48 -0000 Received: (qmail 2778 invoked by uid 22791); 10 Dec 2007 20:49:48 -0000 X-Spam-Check-By: sourceware.org Received: from mail3.panix.com (HELO mail3.panix.com) (166.84.1.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Dec 2007 20:49:41 +0000 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id C679713A7A7; Mon, 10 Dec 2007 15:49:38 -0500 (EST) Received: from [192.168.1.60] (pool-70-104-128-222.nycmny.fios.verizon.net [70.104.128.222]) by mailspool2.panix.com (Postfix) with ESMTP id AACA73DEB6; Mon, 10 Dec 2007 15:49:38 -0500 (EST) Message-ID: <475DA662.6050700@naturalbridge.com> Date: Mon, 10 Dec 2007 20:49:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Richard Guenther CC: Toon Moene , Jakub Jelinek , gcc-patches@gcc.gnu.org, Nathan Froyd , Mark Mitchell , Diego Novillo Subject: Re: [lto] set alias info, poorly 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> In-Reply-To: <84fc9c000712101209i471600f0v6f0533248b0cd3d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00482.txt.bz2 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. Kenny