From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10231 invoked by alias); 26 Sep 2009 20:41:25 -0000 Received: (qmail 10222 invoked by uid 22791); 26 Sep 2009 20:41:25 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Sep 2009 20:41:21 +0000 Received: from relay2.suse.de (mail2.suse.de [195.135.221.8]) by mx2.suse.de (Postfix) with ESMTP id 6D39E86391; Sat, 26 Sep 2009 22:41:18 +0200 (CEST) Date: Sat, 26 Sep 2009 22:24:00 -0000 From: Richard Guenther To: Eric Botcazou Cc: gcc@gcc.gnu.org Subject: Re: On VIEW_CONVERT_EXPRs and TBAA In-Reply-To: <200909262226.36100.ebotcazou@adacore.com> Message-ID: References: <200909262226.36100.ebotcazou@adacore.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00551.txt.bz2 On Sat, 26 Sep 2009, Eric Botcazou wrote: > > With VIEW_CONVERT_EXPR you can also easily create the situation > > where for a reference tree, let it be VIEW_CONVERT_EXPR (X.a).b > > like commonly seen in Ada, the alias-set of the outermost component > > is not a subset of that of the innermost one (the relationship that > > is usually assured to be true by the record_component_aliases > > machinery). You are probably safe here if only your frontend generates > > such conversions and it is very consistent on how it balances > > V_C_Es with accesses through pointers (because in the above case > > if .b is an addressable component an access via a pointer to type > > of b wouldn't necessarily alias the cited reference tree). > > I presume you're talking exclusively about the addressable case here, because > in Ada the alias set of (the type of) the outermost component is not a subset > of (that of) the innermost one by default (at least for scalar types, it is > for aggregate types because of implementation limitations), there being a VCE > or not; the field must explicitly be declared addressable. Yes, addressable in the way that get_alias_set would not skip the component as component_uses_parent_alias_set. > > So, what I'd like to know is in which circumstances the Ada > > frontend uses VIEW_CONVERT_EXPRs and what counter-measures it > > applies to ensure consistent TBAA. > > The Ada compiler generates a lot of VIEW_CONVERT_EXPRs for conversions between > aggregate (sub)types because it generates a lot of aggregate subtypes from a > given aggregate type. These conversions are purely formal and their purpose > is to ensure type consistency. The Ada compiler also uses VIEW_CONVERT_EXPR > to implement up-casting > > type Base is tagged record > I : Integer; > end record; > > type Derived is new Base with record > J : Integer; > end record; > > D : Derived; > Base (D).I > > is translated into VIEW_CONVERT_EXPR(d).i (a questionable use of VCE, no > doubt about that). C++ for this case has a FIELD_DECL in Derived of type Base, so the middle-end sees d..i here (and thus also automatically gets the TBAA hierarchy correct by means of recording component aliases). The Ada way doesn't look too obscure to me. > There are a few other, more obscur uses, but we get rid > of the most controversial one (optimization barrier on scalars for VRP). > > The main countermeasure to ensure consistent TBAA is decl.c:relate_alias_sets > which is aimed at doing the right thing when types are VCEd to each other. Ok, thanks. Richard.