Re: altivec patches

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Tue, 6 Nov 2001 23:16:48 -0800
> From: Richard Henderson <rth@redhat.com>
> Cc: aldyh@redhat.com, gcc-patches@gcc.gnu.org
> Mail-Followup-To: Richard Henderson <rth@redhat.com>,
> 	Geoff Keating <geoffk@redhat.com>, aldyh@redhat.com,
> 	gcc-patches@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> 
> On Mon, Nov 05, 2001 at 01:58:06PM -0800, Geoff Keating wrote:
> > > - #define STACK_BOUNDARY (TARGET_32BIT ? 64 : 128)
> > > + #define STACK_BOUNDARY ((TARGET_32BIT && !TARGET_ALTIVEC_ABI) ? 64 : 128)
> > > - #define BIGGEST_ALIGNMENT 64
> > > + #define BIGGEST_ALIGNMENT (TARGET_ALTIVEC_ABI ? 128 : 64)
> > 
> > I think you _don't_ want this to be dependent on the ABI.  Changing
> > this isn't an ABI change (I hope!), which is good because...
> 
> Yes it is.  REGNO_POINTER_ALIGN(STACK_POINTER_REGNUM) == STACK_BOUNDARY.
> 
> Remember that STACK_BOUNDARY != PREFERRED_STACK_BOUNDARY, and that the
> later does not help you unless you also have code to enforce stack
> alignment, like we're supposed to have for x86 vector code.

Here I was talking about BIGGEST_ALIGNMENT only.  Changing
STACK_BOUNDARY is of course an ABI change.

> > The DWARF_FRAME_REGISTERS change seems to have gone away, which is not
> > quite right:  it has to happen _only when the ABI is 'altivec'_.
> 
> I _think_ you don't have to worry about this any longer.  The ia64
> eh library interface does not expose the number of registers
> involved.  
> 
> We might ought to have checks added to die more gracefully if the
> target adds registers, since we do statically allocate this space
> and older libgcc would not be able to unwind for newer gcc code.

The complexities of this boggle my mind.  I think we haven't even
decided on how some of the pieces should work yet.

Can we really change the EH library interface like this?  Even in the
presence of a glibc compatibility layer to support pre-gcc3.0 C++
binaries?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>