From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10820 invoked by alias); 18 Apr 2003 10:29:42 -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 10791 invoked from network); 18 Apr 2003 10:29:38 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 18 Apr 2003 10:29:38 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA16537; Fri, 18 Apr 03 06:33:54 EDT Date: Fri, 18 Apr 2003 11:41:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10304181033.AA16537@vlsi1.ultra.nyu.edu> To: rth@redhat.com Subject: Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org X-SW-Source: 2003-04/txt/msg00902.txt.bz2 > No, it's being overloaded for two *other* meanings: > > (1) The user really did set the alignment of the object. > (2) The user really did set the alignment of the object's *type*. I see the two as equivalent. I see them as very different because the semantics of setting the alignment of a type and of an object are fundamentally different. The first has both efficiency and code generation impact, but the second has only the latter. This is codified in the Ada RM, but actually applies to all languages. When you set the alignment of a *type*, you are making an interface statement about that type, more specifically about pointers to that type. You are requiring the compiler to align any objects of that type that it creates to be at least as aligned as you specify but *also* stating that any objects of that type *imported* to the code will have that minimum alignment, but aren't guaranteeing it will have more than that alignment. So the compiler is not permitted to assume a larger alignment when it generates code to access objects of that type (via a pointer, when it knows nothing else about the object itself). This means that the specification of the alignment of a type bounds the compiler on both sides: it must ensure that any object it makes is *no less* aligned, but it cannot generate code that assumes the alignment is *more* than that specified. So if the alignment of a type is specified, the alignment of the type cannot be changed by the compiler: it must either honor that alignment or give an error. But specifying the alignment of an *object* is very different. It's not making a statement about an interface, but about efficiency. If I specify the alignment of an object, I'm asserting that I've analyzed accesses to the object and determined the optimal alignment. In which cases is the compiler allowed to override a user-specified alignment? Well, for types it must *never* override the alignment since that would be an interface violation. For objects, if an object is at least as aligned as that requested, it's fine, so I'd argue that a compiler should feel free to over-align an object for efficiency reasons even if the type's alignment is specified because there's no reason not to. On the other hand, if the *object's* alignment is specified, one can presume it was done with a knowlege of what the optimal alignment was so that overriding it is not a good idea. However, if it *has* to be overriden, such as for the minimum alignment of S390, it certainly *should* be since it's not an error to increase the alignment of an object (as opposed to a type). But, in some sense, this isn't even the point. My major point is that decision of what alignment to actually give an object may depend on lots of things, including: (1) the target machine (2) the language (3) the mode and alignment of the type (4) whether the alignment of the type was user-specified (5) the alignment of the object (6) whether the alignment of the object was user-specified What we're doing now is not providing #6, but instead providing the "or" of #4 and #6. I see no justification for elminating potentially-useful information.