From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2442 invoked by alias); 25 Nov 2004 20:55:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2320 invoked from network); 25 Nov 2004 20:55:00 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 25 Nov 2004 20:55:00 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAPKssn1031738 for ; Thu, 25 Nov 2004 15:54:59 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAPKsqr11427; Thu, 25 Nov 2004 15:54:53 -0500 Received: from vpn83-123.boston.redhat.com (IDENT:U2FsdGVkX18RG9MhlTAbgFBaz97S1NivzpN5nmRvhWo@vpn83-123.boston.redhat.com [172.16.83.123]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iAPKsmoS021898; Thu, 25 Nov 2004 15:54:49 -0500 Subject: Re: [RFC] ignoring type alias conflicts between structures and scalars From: Diego Novillo To: Jeff Law Cc: "gcc@gcc.gnu.org" In-Reply-To: <1101415301.13475.58.camel@localhost.localdomain> References: <1101396789.31231.84.camel@localhost.localdomain> <1101415301.13475.58.camel@localhost.localdomain> Content-Type: text/plain Organization: Red Hat Canada Date: Thu, 25 Nov 2004 20:58:00 -0000 Message-Id: <1101416086.12517.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00994.txt.bz2 On Thu, 2004-11-25 at 13:41 -0700, Jeffrey A Law wrote: > I don't think that patch is as-is safe. You have to know something > about the objects. Specifically that one is in global memory and > that the other object is referenced via simple structure references > (as opposed to pointer indirections). > Hmm? But if we just have a structure reference and a global variable, we won't ever have this problem. The aliasing code doesn't look at those. It only ever looks at pointers vs addressable variables. It doesn't care about other variables. > Hmm, maybe we're losing each other on the structure reference stuff; > I might be responsible for that by writing x->y when I meant x.y > The former has pointer indirection, at which points all bets are > likely off. > Yeah, that was probably it. If you meant x.y then we will never even consider x and the global for aliasing. The problem is when you have x- >y. The original code that you sent me had a pointer to a 'struct basic_block_def' and a global variable of type 'int'. Too bad this is not well defined in the standard. We could've gotten a pretty decent gain if we could ignore these kinds of aliases. Diego.