From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3751 invoked by alias); 10 Dec 2007 13:55:45 -0000 Received: (qmail 3736 invoked by uid 22791); 10 Dec 2007 13:55:43 -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 13:55:34 +0000 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id 8ADC813A84B; Mon, 10 Dec 2007 08:55:31 -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 741DB3DF86; Mon, 10 Dec 2007 08:55:31 -0500 (EST) Message-ID: <475D4552.6090306@naturalbridge.com> Date: Mon, 10 Dec 2007 13:55:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Jakub Jelinek CC: Richard Guenther , 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> In-Reply-To: <20071207105948.GE13207@devserv.devel.redhat.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/msg00446.txt.bz2 Jakub Jelinek wrote: > On Fri, Dec 07, 2007 at 11:47:46AM +0100, Richard Guenther wrote: > >> On Dec 6, 2007 11:29 PM, Nathan Froyd wrote: >> >>> First, the good news about this patch: it fixes a few failing testcases. >>> >>> The bad news is that it does it with a very heavy hammer. We say that >>> every type can alias every other type. Obviously this wreaks havoc with >>> all the clever alias analysis that has gone into GCC over the years. >>> >>> There are better, cleverer, more involved ways that you could fix this. >>> But this demonstrably works right now. Ideas on what to do in the >>> future welcome. >>> >> I believe we have to write out the alias sets and the conflict map and at the >> point we combine types of different translation units we have to merge the >> alias sets and conflict maps properly. >> > > Yeah, basically write LTO's own get_alias_set langhook, which will act as > the C one for C CUs, as C++ for C++ CUs, as Fortran for Fortran CUs etc. and > additionally define what kind of aliasing is/is not possible for types > passed from one language to a different one. > > Jakub > What Nathan did not say was that he was doing this at the direction of Diego, Mark and myself. We had a conference call to discuss how to deal with this issue, both in the short term and the long term. This was the short term solution and all of us understood that this is not a particularly good short term solution. The longer term solution will be quite complex and is at this point not well understood. Nathan's patch turns off the part of the alias analysis where the front end gets to make the final decision if two types alias. My personal take on how to reimplement this langhook is that we will end up tagging every type with an indication of which front end it came from. 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. If the two types come from different front ends, then the question will be resolved using a language dependent, and therefore relatively pessimistic, structural test. I do not like doing this, but the aliasing rules for different languages are quite different and cost of just ignoring them is quite high. I know that different people on that call have different takes on this than mine. At the very least this is something that requires a lot of discussion by not just us, but the entire community as well the resources to implement what is likely to be a lot of work. We certainly did not have a simple solution that did better. Writing out the alias sets and then trying to merge them when the input comes from different languages seems to me to be a bad way to go. However, the view of the people on the call was that we had to go for correctness and coverage right now so that the community had something stable to play with. Kenny