From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22735 invoked by alias); 24 Apr 2003 19:52:24 -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 22162 invoked from network); 24 Apr 2003 19:51:03 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 24 Apr 2003 19:51:03 -0000 Received: from prospero.boston.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h3OJp2V21966; Thu, 24 Apr 2003 15:51:02 -0400 Received: by prospero.boston.redhat.com (Postfix, from userid 4046) id DFCF6F8CF4; Thu, 24 Apr 2003 15:47:39 -0400 (EDT) To: Geert Bosch Cc: Alexandre Oliva , kenner@vlsi1.ultra.nyu.edu (Richard Kenner), gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org, Jakub Jelinek , Richard Henderson , Jason Merrill Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT From: Jason Merrill In-Reply-To: <5E98DB9A-768B-11D7-A844-00039344BF4A@gnat.com> (Geert Bosch's message of "Thu, 24 Apr 2003 15:31:39 -0400") References: <5E98DB9A-768B-11D7-A844-00039344BF4A@gnat.com> Date: Thu, 24 Apr 2003 23:24:00 -0000 Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg01253.txt.bz2 On Thu, 24 Apr 2003 15:31:39 -0400, Geert Bosch wrote: > On Thursday, Apr 24, 2003, at 13:16 America/New_York, Jason Merrill wrote: >> I was referring to what dewar said here: >> >> On Mon, 21 Apr 2003 17:35:51 -0400 (EDT), dewar@gnat.com (Robert Dewar) >> wrote: >> >>> type A is ... >>> >>> B : A; >>> for B'Alignment use 4; >>> >>> Put_Line (Integer'Image (B'Alignment)); >>> >>> This must output 4. Of course the compiler could still silently put >>> B on a bigger alignment, since there would be no way to tell that it >>> was doing this systematically, but this would be a poor implementation. >> To me, this means that DECL_ALIGN for B must be exactly 4, whereas giving >> A a TYPE_ALIGN of 4 would only mean that DECL_ALIGN for B must be at >> least 4. > > Exactly. A TYPE_ALIGN of 4 means that any variable of the type is > aligned to at least 4. So the maximum alignment the compiler can > assume for any pointer to a 4-byte aligned type is 4. Agreed. >>> Specifying an alignment for an object means "don't reduce". Of course >>> the compiler should have a good reason to increase, but that's a >>> quality of implementation issue. For example, a compiler might well >>> align all 14-byte local objects of a 2-byte aligned type to 16 bytes >>> and then take advantage of that stricter alignment in code generation. > >> This seems to conflict with what dewar is saying. > No it does not. Note that this is the case where no DECL_ALIGN has been > specified. Huh? The testcase quoted above specifies the alignment for an object, which to me means setting DECL_ALIGN. > Such as: > type T is record > X, Y, Z : Unsigned_16; -- 16-bit unsigned type > end T; > for T'Size use 48; -- 48 bits > for T'Alignment use 2; > > R : T := (1, 2, 3); > Put (R'Alignment); > > This may output a value that is a multiple of 2. Agreed. But what do you think about dewar's testcase? >> 1) For types, we want to be able to force a minimum alignment for >> efficiency/correctness of access. >> 2) For fields, we want to be able to force a minimum alignment. >> 3) For fields, we want to be able to reduce alignment for packing >> efficiency. > Note where you write "field", this really means "component of a > composite type", where a composite type can either be a record > or array. Good point. But how would this be represented for an array? I suppose by reducing TYPE_ALIGN on the element type, so we need to be able to do that as well. >> 4) For objects, we want to be able to force a minimum alignment. > Yes, where minimum alignment is not smaller than the type alignment. Yes. >> 5) For objects, we want to be able to force an exact alignment for >> building up special sections (and for other reasons?). > How would this interact with reordering of objects (for example, > sorting by decreasing size, or for increasing cache efficiency)? > Also, do we guarantee that the compiler will not decide to output > extra objects between user-defined ones? Good point; presumably we would want the same flag to suppress all such optimizations. >> 1 is handled by TYPE_ALIGN/TYPE_USER_ALIGN. >> 2 and 4/5 are handled by DECL_ALIGN/DECL_USER_ALIGN. >> 3 is handled by DECL_PACKED. >> >> It seems to me that the question people have been arguing about is what >> to do about the distinction between 4 and 5. I think that >> DECL_USER_ALIGN was intended to mean 2, which logically extends to 4. > Agreed. >> >> rth's patch of 2001-08-15 changed it to mean 5. >> >> It makes sense to inherit DECL_USER_ALIGN from TYPE_USER_ALIGN if it >> means 4, but not if it means 5; that's why we're seeing the S/390 problem. > > I don't think inheriting is a good idea, even for 4. This way > we loose the capability to over-align objects for which no specific > alignment was specified. No, we don't. 4 just specifies a minimum; you can still over-align such an object. According to dewar, specifying the alignment for an object in Ada means both 4 and 5. It's not clear to me that we want the internal representation to work the same way. > It is important that we can do this, especially as it allows small > records to be stored in registers. Agreed. >> There would seem to be two ways to fix this: >> >> A) Stop inheriting DECL_USER_ALIGN from TYPE_USER_ALIGN on VAR_DECLs. >> B) Change DECL_USER_ALIGN to mean 4, and use DECL_PACKED to mean 5. >> >> I'm partial to solution B. Other opinions? > > I'm in favor of A, since it differentiates between the case where > the compiler has freedom to choose the alignment that gives the > most efficient code on each machine and the case where the user > has good reasons to pin down the details. Both solutions do that. It's just a question of which flag to use internally. Jason