This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: HP-UX PA long double alignment change
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: dave at hiauly1 dot hia dot nrc dot ca (John David Anglin)
- Cc: rth at redhat dot com, sje at cup dot hp dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 4 Dec 2002 21:14:03 -0500 (EST)
- Subject: Re: HP-UX PA long double alignment change
> So if I understand correctly, you are suggesting that we drop
> BIGGEST_ALIGNMENT back to 64 and increase STACK_BOUNDARY to 128.
> I think then the STARTING_FRAME_OFFSET would have to increase
> to 16. Otherwise, we never have a zero frame size. This will
> add two more unused slots in the stack frame which I don't much
> like.
In the discussion that led to the original change, Richard wrote:
> On Fri, Jan 18, 2002 at 06:35:40PM -0800, Aldy Hernandez wrote:
> > this patch introduces a new macro STARTING_FRAME_PHASE (documented).
>
> There is no need for a new macro. The frame pointer _must_ be
> aligned, as we assert here:
>
> emit-rtl.c:4719: REGNO_POINTER_ALIGN (FRAME_POINTER_REGNUM) = STACK_BOUNDARY;
>
> therefore it must always be the case that
>
> sb = STACK_BOUNDARY / BITS_PER_UNIT;
> off = STARTING_FRAME_OFFSET % sb;
>
> STARTING_FRAME_PHASE == (off ? sb - off : 0)
In diagnosing why we never had a zero frame size on hppa64, I found
that when STARTING_FRAME_PHASE % sb is non zero you can never get a
frame size of zero. This seems like a bug as it wastes stack space
if you increase STARTING_FRAME_OFFSET so that off==0.
dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)