From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29090 invoked by alias); 5 Mar 2008 09:21:48 -0000 Received: (qmail 29082 invoked by uid 22791); 5 Mar 2008 09:21:47 -0000 X-Spam-Check-By: sourceware.org Received: from ns2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Mar 2008 09:21:27 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id CEB7439642; Wed, 5 Mar 2008 10:21:24 +0100 (CET) Date: Wed, 05 Mar 2008 09:21:00 -0000 From: Richard Guenther To: Richard Kenner Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Make alias_sets_conflict_p less conservative In-Reply-To: <10803042355.AA00168@vlsi1.ultra.nyu.edu> Message-ID: References: <10803042355.AA00168@vlsi1.ultra.nyu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2008-03/txt/msg00288.txt.bz2 On Tue, 4 Mar 2008, Richard Kenner wrote: > > This makes alias_sets_conflict_p less conservative. rev 34373 (Kenner) > > added a check that makes a structure containing a member with alias > > set zero alias everything. Which IMHO is non-obvious and pessimizes > > for example the testcase in PR27799. Richard, can you explain this > > change? > > I'm not certain, but I think it goes like this: if a structure has > a member with alias set X (nonzero), we normally mark the alias sets > in such a way that the alias set of the structure as a whole conflicts > with alias set X. But if X is zero, the subsetting mechanism doesn't > allow doing that. So we have to do it explicitly, like in this code. Well, this is not what happens. The subsetting code doesn't allow for _sub_setting alias set zero, not for putting alias set zero in a subset. So, if we have struct S { int i; char c; }; struct B { double x; }; then we at the moment say that the alias sets of S and B conflict just because S has a subset that includes alias set zero. This is bogus. Alias set zero only comes into play if either argument of alias_sets_conflict_p is zero, which is handled by the alias_sets_must_conflict_p code already. It actually doesn't matter if we insert alias set zero into subsets at all here, as alias set zero is special. > In other words, this is exactly analogous to the non-zero alias set > of a field case. ? It is not. The patch bootstrapped fine with a single failure, FAIL: gcc.c-torture/execute/20071219-1.c execution where it looks we get things right on the tree level but break it on the RTL level. (It's test3 () that is broken, from a quick look we DSE *p = a; which of course is wrong as p points to b) Richard.