From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11108 invoked by alias); 5 Mar 2008 16:27:15 -0000 Received: (qmail 11100 invoked by uid 22791); 5 Mar 2008 16:27:15 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Mar 2008 16:26:55 +0000 Received: from Relay1.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 C9D3D3994B; Wed, 5 Mar 2008 17:26:52 +0100 (CET) Date: Wed, 05 Mar 2008 16:27:00 -0000 From: Richard Guenther To: Richard Kenner Cc: gcc-patches@gcc.gnu.org, joseph@codesourcery.com, matz@suse.de Subject: Re: [PATCH] Make alias_sets_conflict_p less conservative In-Reply-To: <10803051624.AA07978@vlsi1.ultra.nyu.edu> Message-ID: References: <10803042355.AA00168@vlsi1.ultra.nyu.edu> <4aca3dc20803041620g70075ae3h40d22a4531ad7566@mail.gmail.com> <10803050136.AA01130@vlsi1.ultra.nyu.edu> <10803051132.AA03852@vlsi1.ultra.nyu.edu> <10803051226.AA04718@vlsi1.ultra.nyu.edu> <10803051256.AA05161@vlsi1.ultra.nyu.edu> <10803051426.AA05981@vlsi1.ultra.nyu.edu> <10803051515.AA06678@vlsi1.ultra.nyu.edu> <10803051624.AA07978@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/msg00336.txt.bz2 On Wed, 5 Mar 2008, Richard Kenner wrote: > > Err, right. But tree aliasing is computing a representation for TBAA, > > using alias set conflict queries but _not_ looking at individual accesses. > > That seems quite wrong to me. > > > So, is alias_set_subset_of () wrong as currently implemented? Does > > it lack the ase->has_zero_child test in your opinion? Otherwise I'll > > try using that for these queries. > > I don't know enough to answer those questions. That is sad, because you knew enough to fix exactly the same code in alias_sets_conflict_p. > What I *do* know is that if you have x.y, with y addressable, any code > that looks at the alias set of X *for any reason* is broken. Well, you obviously do not have enough knowledge of the alias representation used in tree-ssa and I won't try to start to explain. If you want, take the testcase in PR27799, build with -O2 -fdump-tree-salias-vops-details and look at the 052t.salias dump. Richard.