This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Altivec + 16 byte alignment


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]