This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Altivec + 16 byte alignment
- From: Geoff Keating <geoffk at geoffk dot org>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: 11 Feb 2003 12:00:39 -0800
- Subject: Re: Altivec + 16 byte alignment
- References: <10302111946.AA20111@vlsi1.ultra.nyu.edu>
kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> Such code is wrong, it should be using MAX_OFILE_ALIGNMENT. Can you
> point at the code in question?
>
> The one in combine.c I mentioned in my last message, for example.
That code seems correct. If there's a problem with it, it must be
that either REGNO_POINTER_ALIGN is being set to an incorrect value or
user error.
> Yes, it's supposed to be. STACK_BOUNDARY is a minimum, not a maximum.
>
> I don't follow. STACK_BOUNDARY indeed gives the mimimum that the stack
> is guaranteed to be aligned. That's therefore the maximum that we can
> guarantee to align any variable.
No. Your logic is flawed. Just because the minimum price for an
apple is $0.01, that doesn't mean I can't guarantee that my apples
cost at least $0.50.
> In the abstract, you compare with MAX_OFILE_BOUNDARY. You can align
> the stack to any value you like,
>
> Who's the "you"? Where's the code? If we have STACK_BOUNDARY of 32,
> MAX_OFILE_BOUNDARY of 1024 and a TYPE_ALIGN of 128, what code is
> responsible for aligning that variable to a boundary of 128 bits?
You, Richard Kenner.
The code is, naturally, machine-dependent. For rs6000, I believe it's
not implemented yet. For x86, it's in ix86_compute_frame_layout, look
for the variable 'stack_alignment_needed'.
> /* 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.
>
> Now we have *yet another* macro involved in alignment!
Yes, there are dozens of macros involved in alignment, they're all
documented, they've all been around for years, I don't understand your
surprise.
--
- Geoffrey Keating <geoffk@geoffk.org>