Re: Altivec + 16 byte alignment

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Tue, 11 Feb 03 14:06:22 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Cc: gcc@gcc.gnu.org

>     BIGGEST_ALIGNMENT is defined in the documentation as:
> 
>     `BIGGEST_ALIGNMENT'
>          Biggest alignment that any data type can require on this machine,
>          in bits.
> 
> Right.  That's what I mean that it's unclear.  Code acts like it means the
> largest alignment that can be guaranteed, but the above is ambiguous at best.

Such code is wrong, it should be using MAX_OFILE_ALIGNMENT.  Can you
point at the code in question?

>     >   If so, how *do* you find the largest alignment you can guarantee?
> 
>     For error checking?  MAX_OFILE_ALIGNMENT is probably the value you
>     want.
> 
> But that's even worse!  It's *larger* than STACK_BOUNDARY.

Yes, it's supposed to be.  STACK_BOUNDARY is a minimum, not a maximum.

> My question is this: suppose a user says "I need this variable or type
> aligned to an N bit boundary".  How can you tell, as a function of N,
> whether you can do that or not?

In the abstract, you compare with MAX_OFILE_BOUNDARY.  You can align
the stack to any value you like, but you can't do better than
MAX_OFILE_BOUNDARY in the object file.


At present, there's this code in assign_stack_local:

  /* Ignore alignment we can't do with expected alignment of the boundary.  */
  if (alignment * BITS_PER_UNIT > PREFERRED_STACK_BOUNDARY)
    alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;

but really that's wrong, and at a minimum it should warn the user
that their requested alignment isn't going to happen (better would be
to just ensure the requested alignment).  We occasionally get bug
reports about this, but so far no-one has invested the effort to
implement arbitrary stack alignment.

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