This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Provide macro to override limiting field alignment
- From: Fred Forsman <forsman at apple dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 11 Dec 2001 12:05:59 -0800
- Subject: Re: [PATCH] Provide macro to override limiting field alignment
On Monday, December 10, 2001, at 08:27 PM, Richard Henderson wrote:
> On Mon, Dec 10, 2001 at 06:35:26PM -0800, Fred Forsman wrote:
>> In my proposed patch the LIMIT_FIELD_ALIGN macro is used to replace
>> statements of the form
>> x = MIN (x, maximum_field_alignment);
>> x = LIMIT_FIELD_ALIGN (x);
> Yes. And if you'll examine how maximum_field_alignment is
> initialized, it is _only_ set by user code. You should not
> be modifying this at all.
>> where there is a "usual" maximum_field_alignment of 32 bits which must
>> be overridden for vector data.
> You are confusing maximum_field_alignment and BIGGEST_FIELD_ALIGNMENT.
> The former is part of the implementation of user-specified struct
> packing, the later controls the default ABI.
Thanks for taking the time to work this through with me, Richard. I
don't believe I am confused about the use of maximum_field_alignment.
Let me explain the particular case I am trying to deal with, and perhaps
you can suggest a better way to address the problem.
On Darwin we have two alignment modes, "power" and "mac68k". These are
specified by the user via either pragmas or command line options.
Specifying the mac68k alignment mode has the result of setting
maximum_field_alignment to 16. This worked just fine until AltiVec
vector types were introduced, which require 128-bit alignment of vector
data regardless of the alignment mode in effect. So the patch I was
proposing allows a hook for overriding the normal alignment behavior in
the case of a user-specified struct packing (our mac68k alignment mode)
to handle a special case which is a exception to the usual alignment
constraints of that packing.