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


    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.

    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.

    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?

      /* 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!


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