Re: HP-UX PA long double alignment change

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Tue, Dec 03, 2002 at 02:51:46PM -0500, John David Anglin wrote:
> > Oops, I see that I introduced this problem when I bumped BIGGEST_ALIGMENT
> > to 128 bits last February.  This was required to obtain 128-bit alignment
> > for the ldcw instruction.
> 
> I think this was a mistake.
> 
> The user can set alignment values larger than BIGGEST_ALIGNMENT,
> STACK_BOUNDARY is _still_ set to 64 for 32-bit, so I don't see
> what good changing this value does.

I did some testing.  With BIGGEST_ALIGNMENT set to 128, STACK_BOUNDARY
set to 64, and PREFERRED_STACK_BOUNDARY set to 512, we get 16 byte alignment
for stack locals using __attribute__ ((aligned(16))), as needed for the ldcw
instruction.  If I reduce BIGGEST_ALIGNMENT to 64, then __attribute__
((aligned(16))) no longer aligns stack locals to the specified alignment.
Thus, the February change appears to have had the desired effect.

The address used in the ldcw and ldcd instructions must be 16 byte aligned.
Unless we play games with the lock address, we really need the 16 byte
alignment for stack locals.  Reverting to a stack with a maximimum alignment
of 8 bytes will break existing code that relies on the 16 byte alignment.

Unless there is some better way to address the problem, I think we
need to address the alignment of long doubles as a separate issue.  The
long double alignment is an exception to the strict alignment required
for all other types.

I don't really want to increase STACK_BOUNDARY as this will waste space.
It appears STACK_BOUNDARY and STARTING_FRAME_OFFSET are redundant as I
don't think you would every want a non zero starting phase.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)