Altivec + 16 byte alignment

Altivec + 16 byte alignment

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

Hi,

I'm currently working on a project which uses altivec (as inline
assembly) to perform 3d affine transformations, and some other 3d vector
functions.

I have a problem in that altivec requires all inputs to be 16 byte
aligned, so I am placing my vectors in a structure like this:

struct vector {
	float x,y,z,w;
}__attribute__((aligned(16)));

This seems to work for global variables, but when allocated on the
stack, my structures end up mis-aligned (on to 8-byte boundaries) which
totally screws up the results of the altivec computation.

Is this a compiler problem, or can't the compiler be expected to
guarantee alignments that large?

gcc version 2.95.4 20010319 (prerelease/franzo/20011204)

PS. Is there any documentation about the vector support directly in C? I
hear gcc3 has that feature.

Thanks.

PS. Please CC replies, im not a list subscriber.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[Gianni Mariani]

Gianni Tedesco wrote:

>Hi,
>
>I'm currently working on a project which uses altivec (as inline
>assembly) to perform 3d affine transformations, and some other 3d vector
>functions.
>
>I have a problem in that altivec requires all inputs to be 16 byte
>aligned, so I am placing my vectors in a structure like this:
>
>struct vector {
>	float x,y,z,w;
>}__attribute__((aligned(16)));
>
>This seems to work for global variables, but when allocated on the
>stack, my structures end up mis-aligned (on to 8-byte boundaries) which
>totally screws up the results of the altivec computation.
>
>Is this a compiler problem, or can't the compiler be expected to
>guarantee alignments that large?
>

This is a problem with the malloc implementation.

Most malloc's support 8 byte alignment.  You could specifically tune one 
of the
many malloc packages out there to be 16 byte aligned and hence this 
would solve
your problem.

>
>gcc version 2.95.4 20010319 (prerelease/franzo/20011204)
>
>PS. Is there any documentation about the vector support directly in C? I
>hear gcc3 has that feature.
>
>Thanks.
>
>PS. Please CC replies, im not a list subscriber.
>
>  
>

Re: Altivec + 16 byte alignment

[Michael S. Zick]

On Tuesday 11 February 2003 04:07 am, Gianni Tedesco wrote:
> Hi,
>
> I'm currently working on a project which uses altivec (as inline
> assembly) to perform 3d affine transformations, and some other 3d vector
> functions.
>
> I have a problem in that altivec requires all inputs to be 16 byte
> aligned, so I am placing my vectors in a structure like this:
>
> struct vector {
> 	float x,y,z,w;
> }__attribute__((aligned(16)));
>
> This seems to work for global variables, but when allocated on the
> stack, my structures end up mis-aligned (on to 8-byte boundaries) which
> totally screws up the results of the altivec computation.
>
> Is this a compiler problem, or can't the compiler be expected to
> guarantee alignments that large?
>
> gcc version 2.95.4 20010319 (prerelease/franzo/20011204)
>
> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.
>
> Thanks.
>
> PS. Please CC replies, im not a list subscriber.
Gianni,

A description of one solution can be found in Appendix F of:
ftp://download.intel.com/design/PentiumII/manuals/24512701.pdf
If you are talking about the ia32 hardware.

I do not think gcc 2.95.4 will do that unless you modify the
function prologue generation.

The gcc 3.x.y series has a lot of work done on altivec support
but I can not answer if stack alignment is controllable in any
of them yet.  Perhaps someone working in that area will be
able to respond.

Mike

Re: Altivec + 16 byte alignment

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Tue, 2003-02-11 at 14:26, Michael S.Zick wrote:
> I do not think gcc 2.95.4 will do that unless you modify the
> function prologue generation.

sure, I found yellowdog gcc-altivec which appears to have fixed the
problem but this could just be chance...

> The gcc 3.x.y series has a lot of work done on altivec support
> but I can not answer if stack alignment is controllable in any
> of them yet.  Perhaps someone working in that area will be
> able to respond.

Yes, it would be nice to know definitively, I am hoping to document my
trials and tribulations with altivec on my website.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[Gianni Mariani]

Gianni Mariani wrote:

> Gianni Tedesco wrote:
>
>>
>> This seems to work for global variables, but when allocated on the
>> stack, my structures end up mis-aligned (on to 8-byte boundaries) which
>> totally screws up the results of the altivec computation.
>
..

> This is a problem with the malloc implementation.

I should read the question better next time ... *STACK* ...

....

Well, you could use alloca and simply align it yourself ....

Yours
Dipstick

Re: Altivec + 16 byte alignment

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Tue, 2003-02-11 at 14:49, Gianni Mariani wrote:
> Well, you could use alloca and simply align it yourself ....

Yeah, but that kinda sucks because everywhere in the program where my
'struct vector' (or any struct that includes it) is used people would
have to allocate it, and if they forget to allocate they get no
problems....until its compiled with altivec operations turned on, so may
make things real hard to debug :(

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Altivec + 16 byte alignment

[tm_gccmail]

On Tue, 11 Feb 2003, Gianni Mariani wrote:

> Gianni Tedesco wrote:
> 
> >Hi,
> >
...
> >This seems to work for global variables, but when allocated on the
> >stack, my structures end up mis-aligned (on to 8-byte boundaries) which
> >totally screws up the results of the altivec computation.
> >
> >Is this a compiler problem, or can't the compiler be expected to
> >guarantee alignments that large?
> >
> 
> This is a problem with the malloc implementation.
> 
> Most malloc's support 8 byte alignment.  You could specifically tune one 
> of the
> many malloc packages out there to be 16 byte aligned and hence this 
> would solve
> your problem.

malloc is not responsible for allocating stack space, and therefore cannot
be implicated as the culprit for the set of circumstances he is
describing.

The basic problem is the compiler does not know the alignment of the
staack when the function is entered, so it doesn't know the amount of
offset required to align the stack to a particular boundary.

The only way to solve this is to example the stack pointer at runtime and
mask off bits in it to align the stack, which isn't currently supported
as an option in gcc.

Toshi

Re: Altivec + 16 byte alignment

[Daniel Egger]

On Tue, 2003-02-11 at 11:07, Gianni Tedesco wrote:

> gcc version 2.95.4 20010319 (prerelease/franzo/20011204)

Please do yourself a favour and ditch that Motorola crap. Gcc supports
AltiVec natively since 3.1 and does a much better job at things similar
to your problem.

Your problem is fixed by supplying the -mabi=altivec switch to gcc 3.1
or later as demonstrated by the following dump program:

struct vector {
  float x,y,z,w;
}__attribute__((aligned(16)));
                                                                                
int main (void)
{
  short a = 0;
  struct vector b = {1, 2, 3};
  int c = 4;
  struct vector d = {4, 5, 6};
  printf ("address: %p\n", &a);
  printf ("address: %p\n", &b);
  printf ("address: %p\n", &c);
  printf ("address: %p\n", &d);
}


egger@sonja:~$ gcc  -o test test.c
egger@sonja:~$ ./test
address: 0x7ffff9a8
address: 0x7ffff9b0
address: 0x7ffff9c0
address: 0x7ffff9c8

egger@sonja:~$ gcc  -mabi=altivec -o test test.c
egger@sonja:~$ ./test
address: 0x7ffff9a8
address: 0x7ffff9b0
address: 0x7ffff9c0
address: 0x7ffff9d0

> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.

Check back with altivec.h in gcc 3.1 or later. The C implementation is
horrible though compared to the C++ one realized with overloading.

--
Servus,
       Daniel

Re: Altivec + 16 byte alignment

[Segher Boessenkool]

Gianni Tedesco wrote:

> PS. Is there any documentation about the vector support directly in C? I
> hear gcc3 has that feature.

As this is just GCC's implementation of the Motorola C
extensions for Altivec, why not read their documentation? :)

(Some small things are different with GCC, mainly constant
vector syntax iirc).

"AltiVec Technology Programming Interface Manual"
http://www.motorola.com/SPS/PowerPC/teksupport/teklibrary/manuals/altivecpim.pdf
(The url might have changed; it was here when I got it, but that's
somewhere in 2000).

I also quite like:

"AltiVec Support In MrC[pp]"
ftp://ftp.apple.com/developer/Development_Kits/altivec/altivec_support_in_MrC.pdf

(especially the appendices) although of course not everything
in there is (directly) applicable to GCC.

Hope this helps,


Segher

Re: Altivec + 16 byte alignment

[Michael S. Zick]

On Wednesday 12 February 2003 05:32 am, Segher Boessenkool wrote:
>
> "AltiVec Technology Programming Interface Manual"
> http://www.motorola.com/SPS/PowerPC/teksupport/teklibrary/manuals/altivecpi
>m.pdf (The url might have changed; it was here when I got it, but that's
> somewhere in 2000).
>
Looks like it got archived, try:
http://merchant.hibbertco.com/fs22/deact/fs22/pdf-docs/motorola/altivecpem.rev0.pdf

Mike

Re: Altivec + 16 byte alignment

[John David Anglin]

> > When STACK_BOUNDARY is set to 64, there is one fill word in the frame
> > as a result of the starting frame offset and the need to align it to a
> > STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
> > fill words.
> 
> Eh?  Is the stack pointer aligned or not?

The comment for STACK_BOUNDARY says "GCC for the PA always rounds its
stacks to a 8 * STACK_BOUNDARY boundary, but that happens late in the
compilation process."  The final size and rounding is determined during
reload.  This calculation is done in compute_frame_size.  However, the
value returned is always rounded no matter when it is called.  We add
in STARTING_FRAME_OFFSET if the frame pointer is needed or the size
returned by get_frame_size () is non-zero.  We also add in space for
the outgoing args, register saves, etc.

Hmmm, I see a small bug.  The rounding in compute_frame_size incorrectly
uses STACK_BOUNDARY.  Based on our current methodology, it should be
using PREFERRED_STACK_BOUNDARY.  However, this isn't the answer to your
question.

I will investigate to see why the above occurs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Thu, Feb 13, 2003 at 01:14:30AM -0500, John David Anglin wrote:
> > PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
> > *if* every object file is compiled with this, that we'll get
> > some speedup at runtime, due to fewer misalignment fixups.
> > 
> > But it is *not* ABI mandated, and you have to assume that 
> > someone somewhere may not honor this.
> 
> Yes, it is.

No.  That is not the purpose of PREFERRED_STACK_BOUNDARY.
The ABI mandated quantity is STACK_BOUNDARY.

> I guess you are saying that STACK_BOUNDARY really should be 512...

If that's what the ABI mandates, yes.

> Can you describe under what
> circumstances if any gcc will not be able to align to the preferred
> stack boundary?

None.  That's not the point.

> Looking at the documentation, it says that STACK_BOUNDARY should be set
> to the *minimum* alignment enforced by hardware for the stack pointer
> on the machine.  It doesn't say the ABI mandated value.

Then the docs need updating.

> When STACK_BOUNDARY is set to 64, there is one fill word in the frame
> as a result of the starting frame offset and the need to align it to a
> STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
> fill words.

Eh?  Is the stack pointer aligned or not?



r~

Re: Altivec + 16 byte alignment

[John David Anglin]

> PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
> *if* every object file is compiled with this, that we'll get
> some speedup at runtime, due to fewer misalignment fixups.
> 
> But it is *not* ABI mandated, and you have to assume that 
> someone somewhere may not honor this.

Yes, it is.  It's written in every runtime document that I have looked
at.  HP-UX doesn't perform misalignment fixups, although the linux port
does.  I guess you are saying that STACK_BOUNDARY really should be 512,
although I have the feeling that that's incompatible with the alignment
used for the outgoing argument block.  Can you describe under what
circumstances if any gcc will not be able to align to the preferred
stack boundary?

Looking at the documentation, it says that STACK_BOUNDARY should be set
to the *minimum* alignment enforced by hardware for the stack pointer
on the machine.  It doesn't say the ABI mandated value.  64-bit alignment
of the stack is sufficient for any type, except for lock semaphores.
If the PREFERRED_STACK_BOUNDARY doesn't break down, it might be
possible to set STACK_BOUNDARY to 32 (i.e., the same as PARM_BOUNDARY).

When STACK_BOUNDARY is set to 64, there is one fill word in the frame
as a result of the starting frame offset and the need to align it to a
STACK_BOUNDARY.  If STACK_BOUNDARY were set to 512, we would have 15
fill words.

> > Currently on the PA 32-bit ports, STACK_BOUNDARY
> > is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
> > PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
> > we must define a non-zero STARTING_FRAME_OFFSET and the
> > start of the locals must lie on a STACK_BOUNDARY.
> 
> True, but it's also assumed that they lie on a PREFERRED_STACK_BOUNDARY,
> are they not?.  So I don't see that you're helping much?

I am certain that STARTING_FRAME_OFFSET must lie on a STACK_BOUNDARY.
Otherwise, you never get a zero frame in a leaf function.  I believe this
is because of the alignment specified in init_emit for STACK_POINTER_REGNUM.
This requirement is independent of any alignment requirement for locals.

PREFERRED_STACK_BOUNDARY sets the frame alignment and an upper limit on
the alignment used in assign_stack_local_1.  There doesn't seem to be a
similar limit in assign_stack_temp_for_type.  As far as I can tell,
STARTING_FRAME_OFFSET doesn't need to be a multiple PREFERRED_STACK_BOUNDARY.
The allocation code will simply pad to the alignment needed for the first
local.

PREFERRED_STACK_BOUNDARY is set to the alignment mandated by the ABI
for the stack pointer.  The 64-byte alignment of the frame was
mandated so that compilers could know when data structures allocated
on the stack are cache aligned.  However, we don't get much benefit
from this using GCC.

It would help if user code could align stack data on a cache line for
performance or other purposes.  I believe the patch that I sent early in
this thread, <http://gcc.gnu.org/ml/gcc/2003-02/msg00656.html>, allows
a user to do this.  It also allows using the low bits as tag bits, as
suggested by Fergus Henderson.  However, it doesn't provide the suggested
error checking.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Wed, Feb 12, 2003 at 05:31:20PM -0500, John David Anglin wrote:
> You mean STACK_BOUNDARY?

Yes, sorry.

> > There are passes in gcc, particularly combine, that look
> > at the advertised alignment for a pointer and know that
> > the low bits are zero, and perform optimizations based on
> > this.  If the alignment doesn't exist, the optimizations
> > produce incorrect results.
> 
> I assume that it's actually the value specified by
> PREFERRED_STACK_BOUNDARY stack boundary that is used for
> the above.

No, that would be wrong.

PREFERRED_STACK_BOUNDARY is a suggestion.  The theory is that
*if* every object file is compiled with this, that we'll get
some speedup at runtime, due to fewer misalignment fixups.

But it is *not* ABI mandated, and you have to assume that 
someone somewhere may not honor this.

> Currently on the PA 32-bit ports, STACK_BOUNDARY
> is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
> PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
> we must define a non-zero STARTING_FRAME_OFFSET and the
> start of the locals must lie on a STACK_BOUNDARY.

True, but it's also assumed that they lie on a PREFERRED_STACK_BOUNDARY,
are they not?.  So I don't see that you're helping much?


r~

Re: Altivec + 16 byte alignment

[Gabriel Paubert]

On Wed, Feb 12, 2003 at 11:26:48PM +0100, Franz Sirl wrote:
> On Wednesday 12 February 2003 22:46, Richard Henderson wrote:
> > On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> > > ... and the stack pointer is kept aligned (to 256 bits) by
> > > independent code as well
> >
> > Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
> > compiler maintain this alignment as well?
> 
> Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI.

I believe that they are actually half of this, at least on 32 bit
targets. Alignment constraints of 128 and 64 appear quite frequently 
in the config/rs6000 files.

	Regards,
	Gabriel

Re: Altivec + 16 byte alignment

[John David Anglin]

> If yes, then STACK_ALIGNMENT is set too low.  You should
> advertise what you have.  If no, then calling between two
> functions compiled with different compilers will not 
> preserve the 256 bit alignment you claim.

You mean STACK_BOUNDARY?

> There are passes in gcc, particularly combine, that look
> at the advertised alignment for a pointer and know that
> the low bits are zero, and perform optimizations based on
> this.  If the alignment doesn't exist, the optimizations
> produce incorrect results.

I assume that it's actually the value specified by
PREFERRED_STACK_BOUNDARY stack boundary that is used for
the above.

Currently on the PA 32-bit ports, STACK_BOUNDARY
is 64 (same as BIGGEST_ALIGNMENT and PARM_BOUNDARY) but
PREFERRED_STACK_BOUNDARY is 512.  In part, this is because
we must define a non-zero STARTING_FRAME_OFFSET and the
start of the locals must lie on a STACK_BOUNDARY.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Franz Sirl]

On Wednesday 12 February 2003 22:46, Richard Henderson wrote:
> On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> > ... and the stack pointer is kept aligned (to 256 bits) by
> > independent code as well
>
> Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
> compiler maintain this alignment as well?

Yep, ABI mandated, 256 bits for SYSV, 128 bits for EABI.

> If yes, then STACK_ALIGNMENT is set too low.  You should
> advertise what you have.  If no, then calling between two
> functions compiled with different compilers will not
> preserve the 256 bit alignment you claim.

STACK_ALIGNMENT? I can't find that. Closest I can find is MIPS_STACK_ALIGN. 
Did you think of some other macro? Sounds promising though.

Maybe part of the confusion stems from the overloaded meaning of 
STACK_BOUNDARY, sometimes it means "alignment needed for the stack pointer", 
sometimes "maximum alignment of objects in the frame" or similar it seems.

Hmm, do we have a function like get_frame_max_object_align()? Then each 
backend could adjust alignment of the frame vs. the alignment of the 
stackpointer as required.

> There are passes in gcc, particularly combine, that look
> at the advertised alignment for a pointer and know that
> the low bits are zero, and perform optimizations based on
> this.  If the alignment doesn't exist, the optimizations
> produce incorrect results.

But this certainly isn't a problem if we _increase_ STACK_BOUNDARY like I 
suggested, or?

Franz.

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Wed, Feb 12, 2003 at 10:07:54PM +0100, Franz Sirl wrote:
> ... and the stack pointer is kept aligned (to 256 bits) by 
> independent code as well

Is this 256 bits ABI mandated?  I.e. will a non-gcc ppc
compiler maintain this alignment as well?

If yes, then STACK_ALIGNMENT is set too low.  You should
advertise what you have.  If no, then calling between two
functions compiled with different compilers will not 
preserve the 256 bit alignment you claim.

There are passes in gcc, particularly combine, that look
at the advertised alignment for a pointer and know that
the low bits are zero, and perform optimizations based on
this.  If the alignment doesn't exist, the optimizations
produce incorrect results.


r~

Re: Altivec + 16 byte alignment

[Franz Sirl]

On Wednesday 12 February 2003 01:42, Richard Henderson wrote:
> On Tue, Feb 11, 2003 at 07:29:37PM +0100, Franz Sirl wrote:
> > Now, if we would increase STACK_BOUNDARY to be
> > always 128 on powerpc-linux-gnu, would this affect binary compatibility
> > at all?
>
> Very much so.

I'm feeling dumb, but can you give an example? AFAICS STACK_BOUNDARY only 
affects the alignment of objects on the stack, argument aligning is 
independent from it and the stack pointer is kept aligned (to 256 bits) by 
independent code as well, so how can these objects passed between functions 
without passing pointers to the objects as well?

Franz.

Re: Altivec + 16 byte alignment

[Spundun Bhatt]

On Wed, 2003-02-12 at 09:26, Gianni Tedesco wrote:
> On Tue, 2003-02-11 at 22:33, Spundun Bhatt wrote:
> > On Tue, 2003-02-11 at 10:57, Franz Sirl wrote:
> > > At 19:32 11.02.2003, David Edelsohn wrote:
> > > > >>>>> Franz Sirl writes:
> > > >
> > > >Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
> > > >Franz> submit a patch to set it to 128 in rs6000/linux.h.
> > > >
> > > >         The patch will be wrong and not accepted.
> > > 
> > > Uhm, wrong in which way? Would you mind to explain this a bit?
> 
> I think because the efficient way to do it is for the caller to always
> keep the stack aligned. eg: initial stack pointer is aligned to 16 bytes
> and all functions make sure their stack frames align to 16 also.
> 
> If you have functions with smaller aligned stack and then they call the
> altivec functions then the altivec function would have to look at the
> stack pointer and align it by hand, which would require a conditional
> branch, argh.
> 
Ofcourse you are right. This means that this trick wont work if used in
a library code if the library is used with an older gcc compiler which
doesnt support this bigger alignement. Also wont work if used for
callbacks with the library using the callbacks not suppoirting this
bigger alignement... and may be many other such instances. 
While this does say that there will be a binary incompatibility between
gcc versions... this incompatibility will only be for this wider
alignement issues. This doesnt in *any* way seems to break backward
compatibility. In general whenever a new feature is added to a software,
the new feature is not supposed to work in the older versions but the
backward compatibility needs to be preserved.. right? 
So I think Franz' question is still up in the air.... Unless ofcourse, I
didnt get your point
Thanx 
Spundun
> I guess...
> 
> HTH.

Re: Altivec + 16 byte alignment

[John David Anglin]

> Please let us agree that this is just a bug, regardless of the CPU's
> requirements.  The alignment declaration might be used by the programmer
> to ensure that the lower bits are available for use as tag bits.
> 
> For example, the following program should result in either success
> or a compile error (if the requested alignment is not supported).
> But IMHO it should not result in an assertion failure.
> 
> 	#include <assert.h>
> 	#define ALIGN 32
> 	int main() {
> 		char c __attribute__((aligned(ALIGN)));
> 		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
> 		return 0;
> 	}

You have my vote on the matter.

If we go back to Franz's original reply to my post regarding the
rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY
is 64 unless you give -mabi=altivec (in 3.2+)."   If you look at
assign_stack_temp_for_type and assign_stack_local_1, you will see
that BLKmode objects are aligned to BIGGEST_ALIGNMENT.  Thus, without
-mabi=altivec, you would randomly get an assertion failure, depending
on the stack alignment, if you checked the alignment of structs with
code similar to that above.  In other words, you aren't getting the
alignment of BLKmode stack locals that you have specified in the
backend.  Possibly, this doesn't matter, but it seems inconsistent
and I think would lead to problems if the compiler checked alignment
requests as suggested above.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Richard Kenner]

    The alignment declaration might be used by the programmer to ensure
    that the lower bits are available for use as tag bits.

Exactly.

    For example, the following program should result in either success
    or a compile error (if the requested alignment is not supported).
    But IMHO it should not result in an assertion failure.

	#include <assert.h>
	#define ALIGN 32
	int main() {
		char c __attribute__((aligned(ALIGN)));
		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
		return 0;
	}

This is *desirable* in C, as you say, but the equivalent Ada program is
*required* to have the behavior you want and there are tests to ensure
that it does.

Re: Altivec + 16 byte alignment

[Fergus Henderson]

On 11-Feb-2003, Mike Stump <mstump@apple.com> wrote:
> On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
> > Another issue is GCC's alignment attribute is silently ignored for 
> > stack locals and the documentation doesn't say that.
> 
> Let us agree that this is just a bug, or at least a bug for CPUs that 
> have hard requirements of say 16 bytes (Altivec, SSE) and the user asks 
> for 16 byte alignment and we silently only do 8 byte alignment.

Please let us agree that this is just a bug, regardless of the CPU's
requirements.  The alignment declaration might be used by the programmer
to ensure that the lower bits are available for use as tag bits.

For example, the following program should result in either success
or a compile error (if the requested alignment is not supported).
But IMHO it should not result in an assertion failure.

	#include <assert.h>
	#define ALIGN 32
	int main() {
		char c __attribute__((aligned(ALIGN)));
		assert ((((unsigned long) &c) & (ALIGN - 1)) == 0);
		return 0;
	}

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Tue, Feb 11, 2003 at 12:00:39PM -0800, Geoff Keating wrote:
> 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'.

No, the code does not exist in mainline at all.  It was once
written in a Cygnus branch, but it was really sort of ugly,
and never made it out.

STACK_BOUNDARY is an ABI issue; PREFERRED_STACK_BOUNDARY is an
optimization goal.  However, without forcibly aligning the stack
with AND, one cannot assume more than STACK_BOUNDARY, because 
that's the most we can expect from a different compiler (or gcc
with a different set of options).


r~

Re: Altivec + 16 byte alignment

[Richard Henderson]

On Tue, Feb 11, 2003 at 07:29:37PM +0100, Franz Sirl wrote:
> Now, if we would increase STACK_BOUNDARY to be 
> always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
> all?

Very much so.


r~

Re: Altivec + 16 byte alignment

[Spundun Bhatt]

On Tue, 2003-02-11 at 10:57, Franz Sirl wrote:
> At 19:32 11.02.2003, David Edelsohn wrote:
> > >>>>> Franz Sirl writes:
> >
> >Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
> >Franz> submit a patch to set it to 128 in rs6000/linux.h.
> >
> >         The patch will be wrong and not accepted.
> 
> Uhm, wrong in which way? Would you mind to explain this a bit?
> 
With all the discussion going on... I didnt see any replies to this
question... (I might have missed it... the threading in evolution for
this thread is skrewed up). Can somebody explain why this is wrong? To
me it looks pretty straight forward to simply change STACK_BOUNDARY to
128. Not that I care though.
Hope this helps
Spundun
> Franz.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    And I don't have all the C++ issues.  

As far as I know, stor-layout.c has almost no "C++ issues": the point of
separating layout into different functions was to keep that in the front end.

Re: Altivec + 16 byte alignment

[Robert Dewar]

> I think that's a *very* bad idea: as you say, what stor-layout.c does is
> very complex.  There will be a significant amount of work to keep some other
> code in sync with it.

I must say I agree with Richard here (I have often wanted to move layout into
the front end of Ada, but Richard has always managed to convince me this is
a bad idea). Can you say *why* you are making this decision:

    The C parser I'm working on won't use it to lay out types, since I don't
    use trees.  I'll have to ensure that what stor-layout.c does (during
    lowering) is the same as what I've done.  At least in an initial
    implementation.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     The C parser I'm working on won't use it to lay out types, since I don't
>     use trees.  I'll have to ensure that what stor-layout.c does (during
>     lowering) is the same as what I've done.  At least in an initial
>     implementation.
> 
> I think that's a *very* bad idea: as you say, what stor-layout.c does is
> very complex.  There will be a significant amount of work to keep some other
> code in sync with it.

You may well be right.  As a first shot, though, just to getting
something that works, it's going to be simplest.  I'm not doing any GNU
extensions, so a lot of the complexity with attributes etc. is avoided.
And I don't have all the C++ issues.  Later I'll probably get the info
from stor-layout.c.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    stor-layout.c is part of the front end; it just happens to be part of
    GCC that is shared between all front ends.  And it shows - it's overly
    generic and nearly incomprehensible.

The complexity is not due to being shared between front ends, but rather
due to the complex ABIs involved on various machines.  If you look back at
early versions, it was just about the same amount of complexity when it
was originally written just for C.

    The C parser I'm working on won't use it to lay out types, since I don't
    use trees.  I'll have to ensure that what stor-layout.c does (during
    lowering) is the same as what I've done.  At least in an initial
    implementation.

I think that's a *very* bad idea: as you say, what stor-layout.c does is
very complex.  There will be a significant amount of work to keep some other
code in sync with it.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     Exactly, but now it seems *you're* the one arguing for putting the
>     check in the front end.
> 
> Not necessarily: it can be checked when laying out the type in stor-layout.c.

stor-layout.c is part of the front end; it just happens to be part of
GCC that is shared between all front ends.  And it shows - it's overly
generic and nearly incomprehensible.

The C parser I'm working on won't use it to lay out types, since I don't
use trees.  I'll have to ensure that what stor-layout.c does (during
lowering) is the same as what I've done.  At least in an initial
implementation.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Exactly, but now it seems *you're* the one arguing for putting the
    check in the front end.

Not necessarily: it can be checked when laying out the type in stor-layout.c.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     > struct foo {
>     >   int x __attribute__((aligned (512)));
>     > }
>     > 
>     > which might, or might not, end up on the stack.
> 
>     You could diagnose that when the object of that type is declared, just
>     like we have to make other checks (particularly in C++) at that time.
> 
> That won't work for Ada, where you have to give the error on the type
> definition if you can't support the type in all valid contexts.

Exactly, but now it seems *you're* the one arguing for putting the check
in the front end.

Neil.

Re: Altivec + 16 byte alignment

[Neil Booth]

Neil Booth wrote:-

> > struct foo {
> >   int x __attribute__((aligned (512)));
> > }
> > 
> > which might, or might not, end up on the stack.
> 
> You could diagnose that when the object of that type is declared, just
> like we have to make other checks (particularly in C++) at that time.

I guess you're saying that the middle end only decides the stack layout
later.  I guess.  Thanks for persisting.  8-)

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    > struct foo {
    >   int x __attribute__((aligned (512)));
    > }
    > 
    > which might, or might not, end up on the stack.

    You could diagnose that when the object of that type is declared, just
    like we have to make other checks (particularly in C++) at that time.

That won't work for Ada, where you have to give the error on the type
definition if you can't support the type in all valid contexts.

Re: Altivec + 16 byte alignment

[Neil Booth]

Geoff Keating wrote:-

> > Isn't an even better place to do it in the front end, just after parsing
> > the alignment request?
> 
> You could do it if you discovered that a user-requested stack local
> needed more alignment than assign_stack_local can currently give,
> but it's not clear to me that the front end will always have that
> information, and certainly it doesn't have it when it's just seen the
> alignment request; consider
> 
> struct foo {
>   int x __attribute__((aligned (512)));
> }
> 
> which might, or might not, end up on the stack.

You could diagnose that when the object of that type is declared, just
like we have to make other checks (particularly in C++) at that time.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Let us agree that this is just a bug, or at least a bug for CPUs that 
    have hard requirements of say 16 bytes (Altivec, SSE) and the user asks 
    for 16 byte alignment and we silently only do 8 byte alignment.

Well it's more complex than that because to *know* that we have these
hard requirement, we have to make STRICT_ALIGNMENT take an operand,
which is the mode.

Moreover, the criteria you cite isn't totally clear.  Even if the
alignment isn't *required* and even if it isn't even preferred from an
efficiency standpoint, can we just ignore it?  In Ada, for example,
you cannot since it imposes constraints on the permitted values of
the object's address.  We also assume those constraints in combine.c.

We have to use all the attribues we have about alignmen to deduce two
things, which are the *default* and the *maximum* alignment we'll allow
for each object and type.

Re: Altivec + 16 byte alignment

[Mike Stump]

On Tuesday, February 11, 2003, at 11:59 AM, John David Anglin wrote:
>>       /* 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!
>
> Another issue is GCC's alignment attribute is silently ignored for 
> stack
> locals and the documentation doesn't say that.

Let us agree that this is just a bug, or at least a bug for CPUs that 
have hard requirements of say 16 bytes (Altivec, SSE) and the user asks 
for 16 byte alignment and we silently only do 8 byte alignment.

Re: Altivec + 16 byte alignment

[tm_gccmail]

On Tue, 11 Feb 2003, Richard Kenner wrote:

>     It's just a function call, exposed to the front end.  Nice and clean.
> 
> In which case, why not do it totally in the back end?  I don't see it as
> a big deal, but I'm not sure what you gain by adding a call to that function
> into every front end.

Now that you mention it, I think Naveen's "stack reorgization" patch might
be relevent, since it allows juggling items on the stack around.

You might want to rearrange the stack to minimize the gaps between the
data items if you're supporting multiple aligned stack items.

Toshi

Re: Altivec + 16 byte alignment

[Geoff Keating]

> Date: Tue, 11 Feb 2003 20:28:50 +0000
> From: Neil Booth <neil@daikokuya.co.uk>

> Geoff Keating wrote:-
> 
> > 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.
> 
> Isn't an even better place to do it in the front end, just after parsing
> the alignment request?

You could do it if you discovered that a user-requested stack local
needed more alignment than assign_stack_local can currently give,
but it's not clear to me that the front end will always have that
information, and certainly it doesn't have it when it's just seen the
alignment request; consider

struct foo {
  int x __attribute__((aligned (512)));
}

which might, or might not, end up on the stack.

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

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     It's just a function call, exposed to the front end.  Nice and clean.
> 
> In which case, why not do it totally in the back end?  I don't see it as
> a big deal, but I'm not sure what you gain by adding a call to that function
> into every front end.

Better diagnostics, mainly.

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    It's just a function call, exposed to the front end.  Nice and clean.

In which case, why not do it totally in the back end?  I don't see it as
a big deal, but I'm not sure what you gain by adding a call to that function
into every front end.

    > And then you have the problem of alignment of *types*, where you have to
    > be able to guarantee the alignment for both stack and memory.

    Why is that a problem?

It isn't necessarily, just another case to be concerned about.

Re: Altivec + 16 byte alignment

[Neil Booth]

Richard Kenner wrote:-

>     Isn't an even better place to do it in the front end, just after parsing
>     the alignment request?
> 
> Probably not, since it would then have to know the complex formula used
> to say what's supported and what isn't.

It's just a function call, exposed to the front end.  Nice and clean.

> And then you have the problem of alignment of *types*, where you have to
> be able to guarantee the alignment for both stack and memory.

Why is that a problem?

Neil.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    Isn't an even better place to do it in the front end, just after parsing
    the alignment request?

Probably not, since it would then have to know the complex formula used
to say what's supported and what isn't.

And then you have the problem of alignment of *types*, where you have to
be able to guarantee the alignment for both stack and memory.

Re: Altivec + 16 byte alignment

[Neil Booth]

Geoff Keating wrote:-

> 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.

Isn't an even better place to do it in the front end, just after parsing
the alignment request?

Neil.

Re: Altivec + 16 byte alignment

[Geoff Keating]

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>

Re: Altivec + 16 byte alignment

[Geert Bosch]

On Tuesday, Feb 11, 2003, at 14:06 America/New_York, Richard Kenner 
wrote:
> 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?

I think it would be very useful if the answer would always be yes.
Then, in cases where GCC cannot guarantee proper alignment, extra
code should be generated to properly align the stack frame.

   -Geert

Re: Altivec + 16 byte alignment

[John David Anglin]

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

Another issue is GCC's alignment attribute is silently ignored for stack
locals and the documentation doesn't say that.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Altivec + 16 byte alignment

[Richard Kenner]

    The only way to solve this is to example the stack pointer at runtime
    and mask off bits in it to align the stack, which isn't currently
    supported as an option in gcc.

Well, not for C, but see gcc/ada/decl.c:make_aligning_type, which does
just that.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    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!

Re: Altivec + 16 byte alignment

[David Edelsohn]

>>>>> Geoff Keating writes:

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

	I think part of the confusion is this depends on the type of
storage.  For an automatic variable on the stack, MAX_OFILE_ALIGNMENT is
irrelevant.  For a global or static variable allocated in the data or bss
segment, MAX_OFILE_ALIGNMENT describes the functionality of the
link-editor pre-allocating storage in the process address space.

David

Re: Altivec + 16 byte alignment

[Geoff Keating]

> 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>

Re: Altivec + 16 byte alignment

[Richard Kenner]

    I think the answer is the minimum of MAX_OFILE_ALIGNMENT, 
    STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs.  If there 
    are bugs, you can't, not without fixing those bugs.

Well, then there's another bug.  Look at the usage of REGNO_POINTER_ALIGNMENT
in combine.c: it assumes that the bits not in that alignment are zero.
Then look at all the calls to mark_reg_pointer that just pass TYPE_ALIGN
or DECL_ALIGN but nothing performs the minimum above before setting those.

But I must say that 

    Biggest alignment that any data type can require on this machine, in bits.

still seems in conflict with the current implementation.  If a type can
*require* that alignment, doesn't that mean that we are going to *give*
it that alignment?  But how can we if STACK_BOUNDARY is smaller?

I think this is a real mess at this point.

Re: Altivec + 16 byte alignment

[Mike Stump]

On Tuesday, February 11, 2003, at 11:06 AM, Richard Kenner wrote:
> 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?

I think the answer is the minimum of MAX_OFILE_ALIGNMENT, 
STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs.  If there 
are bugs, you can't, not without fixing those bugs.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    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.

    >   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.

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?

Re: Altivec + 16 byte alignment

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
>     -mabi=altivec (in 3.2+). 
> 
> I must say that I find this confusing.  Although the documentation is
> unclear, I've always thought of BIGGEST_ALIGNMENT as being the largest
> alignment we can guarantee and I think there's code that depends on that.

BIGGEST_ALIGNMENT is defined in the documentation as:

`BIGGEST_ALIGNMENT'
     Biggest alignment that any data type can require on this machine,
     in bits.

> But if STACK_BOUNDARY < BIGGEST_ALIGNMENT, that's clearly not true.  

I don't see that.  The prologue can always try to align the stack
itself, although at some runtime cost.  I think that's what
PREFERRED_STACK_BOUNDARY is all about.

> Has the definition changed?

It's been like this since at least 1997.

>   If so, how *do* you find the largest alignment you can guarantee?

For error checking?  MAX_OFILE_ALIGNMENT is probably the value you
want.

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

Re: Altivec + 16 byte alignment

[Franz Sirl]

At 19:32 11.02.2003, David Edelsohn wrote:
> >>>>> Franz Sirl writes:
>
>Franz> BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give
>Franz> -mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY 
>to be
>Franz> always 128 on powerpc-linux-gnu, would this affect binary 
>compatibility at
>Franz> all? I can't think of a situation where this would happen, but 
>maybe I'm wrong?
>Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
>Franz> submit a patch to set it to 128 in rs6000/linux.h.
>
>         The patch will be wrong and not accepted.

Uhm, wrong in which way? Would you mind to explain this a bit?

Franz.

Re: Altivec + 16 byte alignment

[Richard Kenner]

    BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
    -mabi=altivec (in 3.2+). 

I must say that I find this confusing.  Although the documentation is
unclear, I've always thought of BIGGEST_ALIGNMENT as being the largest
alignment we can guarantee and I think there's code that depends on that.
But if STACK_BOUNDARY < BIGGEST_ALIGNMENT, that's clearly not true.  

Has the definition changed?  If so, how *do* you find the largest
alignment you can guarantee?

Re: Altivec + 16 byte alignment

[David Edelsohn]

>>>>> Franz Sirl writes:

Franz> BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
Franz> -mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY to be 
Franz> always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
Franz> all? I can't think of a situation where this would happen, but maybe I'm wrong?
Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will 
Franz> submit a patch to set it to 128 in rs6000/linux.h.

	The patch will be wrong and not accepted.

David

Re: Altivec + 16 byte alignment

[Franz Sirl]

At 18:25 11.02.2003, John David Anglin wrote:
> > I have a problem in that altivec requires all inputs to be 16 byte
> > aligned, so I am placing my vectors in a structure like this:
> >
> > struct vector {
> >         float x,y,z,w;
> > }__attribute__((aligned(16)));
>
>We had a similar problem with respect to the alignment of data for
>the ldcw instruction on the PA which needs 16-byte alignment on PA 1.X.
>We have found an alternative solution.  However, the patch below
>will allow the aligned attribute to be respected for stack locals
>up to PREFERRED_STACK_BOUNDARY.  Note however, that alignment of
>stack locals is only guaranteed up to STACK_BOUNDARY.  The default
>alignment for structs on the stack is BIGGEST_ALIGNMENT, which I
>presume is set 64 (8 bytes).
>
>It may well be with altvec you really want BIGGEST_ALIGNMENT set to
>256, but the change would affect the ABI and alignment of long doubles.
>The i386 code provides an example of what needs doing if there are
>types such as long doubles that don't require natural alignment.

BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give 
-mabi=altivec (in 3.2+). Now, if we would increase STACK_BOUNDARY to be 
always 128 on powerpc-linux-gnu, would this affect binary compatibility at 
all? I can't think of a situation where this would happen, but maybe I'm wrong?
If changing STACK_BOUNDARY doesn't affect binary compatibility, I will 
submit a patch to set it to 128 in rs6000/linux.h.

Franz.

Re: Altivec + 16 byte alignment

[John David Anglin]

> I have a problem in that altivec requires all inputs to be 16 byte
> aligned, so I am placing my vectors in a structure like this:
> 
> struct vector {
>         float x,y,z,w;
> }__attribute__((aligned(16)));

We had a similar problem with respect to the alignment of data for
the ldcw instruction on the PA which needs 16-byte alignment on PA 1.X.
We have found an alternative solution.  However, the patch below
will allow the aligned attribute to be respected for stack locals
up to PREFERRED_STACK_BOUNDARY.  Note however, that alignment of
stack locals is only guaranteed up to STACK_BOUNDARY.  The default
alignment for structs on the stack is BIGGEST_ALIGNMENT, which I
presume is set 64 (8 bytes).

It may well be with altvec you really want BIGGEST_ALIGNMENT set to
256, but the change would affect the ABI and alignment of long doubles.
The i386 code provides an example of what needs doing if there are
types such as long doubles that don't require natural alignment.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2003-02-11  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	* function.c (assign_stack_temp_for_type): Allow user to increase
	alignment of stack locals up to PREFERRED_STACK_BOUNDARY.

Index: function.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/function.c,v
retrieving revision 1.388
diff -u -3 -p -r1.388 function.c
--- function.c	27 Nov 2002 02:29:12 -0000	1.388
+++ function.c	6 Dec 2002 23:07:56 -0000
@@ -650,6 +650,12 @@ assign_stack_temp_for_type (mode, size, 
   else
     align = GET_MODE_ALIGNMENT (mode);
 
+  /* Allow the user to increase the default alignment with the aligned
+     attribute but bound the range.  */
+  if (type && TYPE_USER_ALIGN (type))
+    align = MIN (MAX (TYPE_ALIGN (type), align),
+		 MAX (PREFERRED_STACK_BOUNDARY, align));
+
   if (! type)
     type = (*lang_hooks.types.type_for_mode) (mode, 0);