[TESTCASE] Minimized testcase for AltiVec segfault

[TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

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

Hija,

the attached testcase will segfault on powerpc-linux when compiled with
-O0.

egger@sonja:~$ /opt/gcc/bin/gcc -da -maltivec -save-temps -O0 -mregnames
test2.c -o test2 -Wall
test2.c: In function `do_something':
test2.c:7: warning: unused variable `zeros'
egger@sonja:~$ ./test2 
Segmentation fault

Works with -O2:
egger@sonja:~$ /opt/gcc/bin/gcc -da -maltivec -save-temps -O2 -mregnames
test2.c -o test2 -Wall
test2.c: In function `do_something':
test2.c:7: warning: unused variable `zeros'
egger@sonja:~$ ./test2 
egger@sonja:~$ 

do_something:
        stwu %r1,-96(%r1)
        stw %r31,92(%r1)
        mr %r31,%r1
        stw %r3,8(%r31)
        lis %r9,.LC0@ha
        la %r9,.LC0@l(%r9)
        lvx %v0,0,%r9
        li %r0,32
        stvx %v0,%r31,%r0
        li %r0,32
        lvx %v0,%r31,%r0
        li %r0,16
        stvx %v0,%r31,%r0
        lwz %r0,8(%r31)
        stw %r0,48(%r31)
        lwz %r9,48(%r31)
        lvx %v0,0,%r9       <--- This is an offending line.
        li %r0,56
        stvx %v0,%r31,%r0
        lwz %r9,48(%r31)
        li %r0,56
        lvx %v0,%r31,%r0
        stvx %v0,0,%r9      <--- This is an offending line.
        lwz %r11,0(%r1)
        lwz %r31,-4(%r11)
        mr %r1,%r11
        blr

One problem with this marked lines is that there is no direct vector
load or vector store with the second argument being 0 to directly
address the memory at the pointer in the third argument which gcc seem
to assume exists.

Even worse for the store is that %r9 points to 0 and %r0 is 56 (while
it is probably assumed to be ignored) which means that address
generation is wrong anyway even if the syntax was right.

-- 
Servus,
       Daniel

[-- Attachment #2: Type: text/x-c, Size: 453 bytes --]

#include <altivec.h>
#include <malloc.h>

void
do_something (signed short *mem)
{
  const vector signed short zeros = (vector signed short) {0,0,0,0,0,0,0};
  vector signed short *vec;
  vector signed short v1[1];

  vec = (vector signed short *) mem;
  
  v1[0] = vec[0];
  vec[0] = v1[0];
}

int
main (void)
{
  void *mem = memalign (128, 16);
  
  if (mem)
  {
    do_something (mem);
    free (mem);
  }
 
  return 0;
}

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[David Edelsohn]

>>>>> Daniel Egger writes:

Daniel> lvx %v0,0,%r9       <--- This is an offending line.
Daniel> stvx %v0,0,%r9      <--- This is an offending line.

Daniel> One problem with this marked lines is that there is no direct vector
Daniel> load or vector store with the second argument being 0 to directly
Daniel> address the memory at the pointer in the third argument which gcc seem
Daniel> to assume exists.

	I believe that you are misinformed about the Altivec instruction
set.  Altivec indexed loads are like PowerPC indexed loads: if rA is zero,
the effective address is 0+rB, not r0+rB.

David

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Die, 2002-02-26 um 17.27 schrieb David Edelsohn:

> 	I believe that you are misinformed about the Altivec instruction
> set.  Altivec indexed loads are like PowerPC indexed loads: if rA is zero,
> the effective address is 0+rB, not r0+rB.

Mea culpa, you're absolutely right. I got that impression from debugging
it with gdb which gets it wrong as does objdump:

100004b4:       90 1f 00 30     stw     r0,48(r31)
100004b8:       81 3f 00 30     lwz     r9,48(r31)
100004bc:       7c 00 48 ce     lvx     v0,r0,r9
100004c0:       38 00 00 38     li      r0,56

The AltiVec PIM does not mention it at all but the PEM does.
 
-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

> the attached testcase will segfault on powerpc-linux when compiled with
> -O0.
>
> egger@sonja:~$ /opt/gcc/bin/gcc -da -maltivec -save-temps -O0 -mregnames

first, you can't possibly do -maltivec and not do -mabi=altivec.
who knows what will happen.

second, it would probably better if you configured with --enable-altivec.
did you do that?  if so, you don't need to pass -maltivec or
-mabi=altivec.

lastly... i can't reproduce on either darwin or ppc linux.

i'm running:

2.4.8-0.4gsmp

if the above suggestions don't fix it, someone else needs to take a look
at it, because i sure can't reproduce it.

> #include <altivec.h>
> #include <malloc.h>
>
> void
> do_something (signed short *mem)
> {
>   const vector signed short zeros = (vector signed short) 
> {0,0,0,0,0,0,0};
>   vector signed short *vec;
>   vector signed short v1[1];
>
>   vec = (vector signed short *) mem;
>
>   v1[0] = vec[0];
>   vec[0] = v1[0];
> }
>
> int
> main (void)
> {
>   void *mem = memalign (128, 16);
>
>   if (mem)
>   {
>     do_something (mem);
>     free (mem);
>   }
>
>   return 0;
> }
>
--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Mit, 2002-02-27 um 05.52 schrieb Aldy Hernandez:

> second, it would probably better if you configured with --enable-altivec.
> did you do that?  if so, you don't need to pass -maltivec or
> -mabi=altivec.

DOH! It does work with -mabi=altivec though you should really explain
to me why it will affect address generation like this:

        lwz 9,48(31)
        lvx 0,0,9
-       li 0,56
+       li 0,64
        stvx 0,31,0
        lwz 9,48(31)
-       li 0,56
+       li 0,64
        lvx 0,31,0
        stvx 0,0,9
        lwz 11,0(1)

If I understand the issues correctly it's just about saving the vector
registers so they don't get clobbered. After all it still might be a bug
which should be fixed.
 
-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

On Thursday, February 28, 2002, at 09:58  AM, Daniel Egger wrote:

> Am Mit, 2002-02-27 um 05.52 schrieb Aldy Hernandez:
>
>> second, it would probably better if you configured with 
>> --enable-altivec.
>> did you do that?  if so, you don't need to pass -maltivec or
>> -mabi=altivec.
>
> DOH! It does work with -mabi=altivec though you should really explain
> to me why it will affect address generation like this:

aha!  told you :)


> registers so they don't get clobbered. After all it still might be a bug
> which should be fixed.
>

it's a bit tricky.  i don't see any way of altivec working without
-mabi=altivec, but we couldn't just blindly modify the abi just because
we had altivec enabled, so we had to add another flag.

it is theoretically possible to use -maltivec without the altivec abi,
but that doesn't make much sense because you won't have VRSAVE set,
you won't get varargs (which are broken right now anyhow :-)) working,
you can't get the stack adjusted properly for the vector arguments,
etc etc.

i think -maltivec without the abi changes is there for somebody who
*really* knows what s/he's doing, has everything aligned properly, and
wants to have a function callable from non altivec compiled functions.

i guess... i can't see other reasons for it.  that's why 
--enable-altivec,
the proper blessed way of building an altivec toolchain, sets the abi
as well.

aldy

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Don, 2002-02-28 um 00.10 schrieb Aldy Hernandez:

> it is theoretically possible to use -maltivec without the altivec abi,
> but that doesn't make much sense because you won't have VRSAVE set,
> you won't get varargs (which are broken right now anyhow :-)) working,
> you can't get the stack adjusted properly for the vector arguments,
> etc etc.

The joke here is: I'm not using vector arguments, nor varargs, I don't
need vectors on the stack and nothing. In theory I should be able to
live without -mabi=altivec if there wasn't this nasty segfault at -O0.

> i think -maltivec without the abi changes is there for somebody who
> *really* knows what s/he's doing, has everything aligned properly, and
> wants to have a function callable from non altivec compiled functions.

That would be me! I know what I'm doing, have no intention to pass
vector arguments or use varargs.
 
-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

>> i think -maltivec without the abi changes is there for somebody who
>> *really* knows what s/he's doing, has everything aligned properly, and
>> wants to have a function callable from non altivec compiled functions.
>
> That would be me! I know what I'm doing, have no intention to pass
> vector arguments or use varargs.

how about local variables?  there are some magic alignment rules
that are keyed off of abi=altivec. ... especially the stack boundary.

how about vrsave?  surely you need vrsave to be set properly, otherwise
the OS will not save your vector registers on a context-switch.

how about the prologue and epilogue?  the altivec registers won't be
saved/restored unless abi=altivec.

some call used registers being altivec?

i guess you could use all global variables, and have the OS
save/restore all vector registers on a context switch (slooow).

these are just a few of the things that came up while poking around
the code (search for TARGET_ALTIVEC_ABI).

perhaps this needs to be readressed and having -maltivec imply an
abi change^Wenhancement.  i for one, wouldn't mind getting
rid of -mabi=altivec, but i believe geoff wanted it that way.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Kumar Gala]

> how about vrsave?  surely you need vrsave to be set properly, otherwise
> the OS will not save your vector registers on a context-switch.

Does -mabi=altivec cause VRSAVE to be updated?.  On Linux, VRSAVE is not
used by the OS to determine which registers to save (all vr regs are saved
on a context switch).

VRSAVE is useful for ABIs which allocate registers in order (ie MacOS)
such that one can mark the last used register and save/restore to that
point.  Otherwise it seems rather painful to manage/update vrsave in one's
code (for SVR4 style register allocation).

If GCC is managing VRSAVE when -mabi=altivec then I think there should be
another flag to disable the use of VRSAVE.  It tends to be a waste of time
to manage as well as hard to use for determining which regs to save by the
context code.


- kumar

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Alex Rosenberg]

on 2/27/02 3:39 PM, Kumar Gala at kumar.gala@motorola.com wrote:

> If GCC is managing VRSAVE when -mabi=altivec then I think there should be
> another flag to disable the use of VRSAVE.  It tends to be a waste of time
> to manage as well as hard to use for determining which regs to save by the
> context code.

"#pragma altivec_vrsave on | off | allon" support would be desirable as
well.

The idea here is to not emit VRSave uses except at an outermost function.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Don, 2002-02-28 um 02.23 schrieb Alex Rosenberg:

> "#pragma altivec_vrsave on | off | allon" support would be desirable as
> well.
 
> The idea here is to not emit VRSave uses except at an outermost function.

Just curious: how's that supposed to work?
 
-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Alex Rosenberg]

on 2/27/02 6:09 PM, Daniel Egger at degger@fhm.edu wrote:

> Am Don, 2002-02-28 um 02.23 schrieb Alex Rosenberg:
> 
>> "#pragma altivec_vrsave on | off | allon" support would be desirable as
>> well.
> 
>> The idea here is to not emit VRSave uses except at an outermost function.
> 
> Just curious: how's that supposed to work?

Suppose you're writing a plugin for an image processing application:

#pragma altivec_vrsave off

void entrypoint(...)
{
#pragma altivec_vrsave allon
  do_work();
}
...

So, the entrypoint function will turn on all bits in VRSave and all other
functions will not manipulate it at all. If lots of small subroutines are
used, the savings add up. (Consider the serialization for m[tf]spr.)

The syntax is outlined in section 2.6 of the AltiVec PIM.

Of course, I realize in suggesting this that pragmas are out of favor with
this crowd and that a new and twisty syntax unique to gcc is likely to
happen instead. However, this functionality has already proven useful to
numerous Mac OS developers, particularly in plugin code with single
entrypoints as for Photoshop or After Effects, so I thought it worthwhile to
call attention to it.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

>>>>> "Alex" == Alex Rosenberg <alexr@spies.com> writes:

 > void entrypoint(...)
 > {
 > #pragma altivec_vrsave allon
 >   do_work();
 > }
 > ..

Well if you're going to do that, why not wrap the entire
program in:

main()
{
	asm("set all vrsave bits to on");
	do stuff
	asm("set all vrsave bits to off");
}

aldy

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Alex Rosenberg]

on 2/27/02 10:07 PM, Aldy Hernandez at aldyh@redhat.com wrote:

>>>>>> "Alex" == Alex Rosenberg <alexr@spies.com> writes:
> 
>> void entrypoint(...)
>> {
>> #pragma altivec_vrsave allon
>> do_work();
>> }
>> ..
> 
> Well if you're going to do that, why not wrap the entire
> program in:
> 
> main()
> {
> asm("set all vrsave bits to on");
> do stuff
> asm("set all vrsave bits to off");
> }

If the inline assembly feature in GCC were even remotely that easy to use,
I'd agree with you.

If you're volunteering to add statement-level inline assembly support with
full scheduling and whatnot a la Metrowerks CodeWarrior, then I'm sure many
many many folks would appreciate it.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

> If the inline assembly feature in GCC were even remotely that easy to 
> use,
> I'd agree with you.

we could add a builtin to set all the vrsave bits on
and another to set them all off.

>
> If you're volunteering to add statement-level inline assembly support 
> with
> full scheduling and whatnot a la Metrowerks CodeWarrior, then I'm sure 
> many
> many many folks would appreciate it.

wishful thinking ;-)
>
> +------------------------------------------------------------+
> | Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
> | Nobody cares what I say. Remove the underscore to mail me. |
>
>
--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

On Thursday, February 28, 2002, at 10:39  AM, Kumar Gala wrote:

>> how about vrsave?  surely you need vrsave to be set properly, otherwise
>> the OS will not save your vector registers on a context-switch.
>
> Does -mabi=altivec cause VRSAVE to be updated?.  On Linux, VRSAVE is not

yes

> used by the OS to determine which registers to save (all vr regs are 
> saved
> on a context switch).

hmm, when i first started coding, i talked to a few linux kernel hackers
and no one was able to tell me wether linux used vrsave or not.
should've talked to the ppc maintainer ;-)

> VRSAVE is useful for ABIs which allocate registers in order (ie MacOS)
> such that one can mark the last used register and save/restore to that
> point.  Otherwise it seems rather painful to manage/update vrsave in 
> one's
> code (for SVR4 style register allocation).

ahh, that wasn't clear from the specs.

> If GCC is managing VRSAVE when -mabi=altivec then I think there should 
> be
> another flag to disable the use of VRSAVE.  It tends to be a waste of 
> time
> to manage as well as hard to use for determining which regs to save by 
> the
> context code.

in which case... you are correct.  we should add a flag to not set 
vrsave.

ahhhctually, i motion we get rid of -mabi=altivec and have -maltivec
imply an abi enhancement.  unless geoff/david or someone else can
think of a reason not to.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Thu, 28 Feb 2002 13:14:34 +1100
> Cc: Daniel Egger <degger@fhm.edu>, GCC Developer Mailinglist <gcc@gcc.gnu.org>,
>    David Edelsohn <dje@watson.ibm.com>, Geoff Keating <geoffk@geoffk.org>
> From: Aldy Hernandez <aldyh@redhat.com>

> ahhhctually, i motion we get rid of -mabi=altivec and have -maltivec
> imply an abi enhancement.  unless geoff/david or someone else can
> think of a reason not to.

No, don't do that.  I can think of lots of reasons not to.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

>> Date: Thu, 28 Feb 2002 13:14:34 +1100
>> Cc: Daniel Egger <degger@fhm.edu>, GCC Developer Mailinglist 
>> <gcc@gcc.gnu.org>,
>>    David Edelsohn <dje@watson.ibm.com>, Geoff Keating 
>> <geoffk@geoffk.org>
>> From: Aldy Hernandez <aldyh@redhat.com>
>
>> ahhhctually, i motion we get rid of -mabi=altivec and have -maltivec
>> imply an abi enhancement.  unless geoff/david or someone else can
>> think of a reason not to.
>
> No, don't do that.  I can think of lots of reasons not to.

care to share?

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Thu, 28 Feb 2002 13:31:00 +1100
> Cc: kumar.gala@motorola.com, degger@fhm.edu, gcc@gcc.gnu.org,
>    dje@watson.ibm.com
> From: Aldy Hernandez <aldyh@redhat.com>
> 
> >> Date: Thu, 28 Feb 2002 13:14:34 +1100
> >> Cc: Daniel Egger <degger@fhm.edu>, GCC Developer Mailinglist 
> >> <gcc@gcc.gnu.org>,
> >>    David Edelsohn <dje@watson.ibm.com>, Geoff Keating 
> >> <geoffk@geoffk.org>
> >> From: Aldy Hernandez <aldyh@redhat.com>
> >
> >> ahhhctually, i motion we get rid of -mabi=altivec and have -maltivec
> >> imply an abi enhancement.  unless geoff/david or someone else can
> >> think of a reason not to.
> >
> > No, don't do that.  I can think of lots of reasons not to.
> 
> care to share?

You'd be deleting a feature, and worse, you'd be re-using the obvious
choice for the option that enables that feature for something
different, making it difficult to re-introduce that feature in future.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

>>> No, don't do that.  I can think of lots of reasons not to.
>>
>> care to share?
>
> You'd be deleting a feature, and worse, you'd be re-using the obvious
> choice for the option that enables that feature for something
> different, making it difficult to re-introduce that feature in future.

a feature that no one would use.

the same people who would want to link old code, wouldn't be able
to write code that use varargs, vector arguments, etc, which is
the reason for -mabi=altivec in the first place.

in other words, if you DONT use -mabi=altivec, you won't be able
to use features XYZ.  so it's just the same to imply -mabi=altivec
from just -maltivec, and have the user just not use features
XYZ if they want to link in old code.

basically, there's no added benefit from using a separate
-mabi=altivec flag, especially if the user claims to know what
they are doing... in which case they achieve the same functionality
by not using varargs, vector arguments, etc.

and as daniel and others have pointed out, having -mabi=altivec
is a bit confusing.

considering what i have just said, what possible use could
-mabi=altivec have?

another alternative, why don't we have altivec abi enhancements
enabled by default for -maltivec, and then have a -mno-altivec-abi
flag?

that looks less intrusive, since the common thing is to have the
altivec abi.-- but i still think i'm right ;-)

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Thu, 28 Feb 2002 16:39:12 +1100
> Cc: kumar.gala@motorola.com, degger@fhm.edu, gcc@gcc.gnu.org,
>    dje@watson.ibm.com
> From: Aldy Hernandez <aldyh@redhat.com>
> 
> >>> No, don't do that.  I can think of lots of reasons not to.
> >>
> >> care to share?
> >
> > You'd be deleting a feature, and worse, you'd be re-using the obvious
> > choice for the option that enables that feature for something
> > different, making it difficult to re-introduce that feature in future.
> 
> a feature that no one would use.
> 
> the same people who would want to link old code, wouldn't be able
> to write code that use varargs, vector arguments, etc, which is
> the reason for -mabi=altivec in the first place.
> 
> in other words, if you DONT use -mabi=altivec, you won't be able
> to use features XYZ.  so it's just the same to imply -mabi=altivec
> from just -maltivec, and have the user just not use features
> XYZ if they want to link in old code.
> 
> basically, there's no added benefit from using a separate
> -mabi=altivec flag, especially if the user claims to know what
> they are doing... in which case they achieve the same functionality
> by not using varargs, vector arguments, etc.

Why can't varargs and vector arguments be supported under the SVR4
ABI?

Isn't altivec still useful even if you can't pass vectors as
arguments?

The significant change that -mabi=altivec makes is that it expects
called procedures to save the call-saved altivec registers.  Thus, you
can't call any non-altivec-abi procedures from an altivec-abi
procedure safely.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

> Why can't varargs and vector arguments be supported under the SVR4
> ABI?

because things won't be aligned properly.  and if they were,
we'd no longer be SVR4 abi compliant.

>
> Isn't altivec still useful even if you can't pass vectors as
> arguments?

sure, but we don't need a flag to do that.

> The significant change that -mabi=altivec makes is that it expects
> called procedures to save the call-saved altivec registers.  Thus, you
> can't call any non-altivec-abi procedures from an altivec-abi
> procedure safely.

this however, makes a lot of sense.
>
> --
> - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
>
>
--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Fri, 1 Mar 2002 09:26:02 +1100
> Cc: kumar.gala@motorola.com, degger@fhm.edu, gcc@gcc.gnu.org,
>    dje@watson.ibm.com
> From: Aldy Hernandez <aldyh@redhat.com>
> 
> > Why can't varargs and vector arguments be supported under the SVR4
> > ABI?
> 
> because things won't be aligned properly.  and if they were,
> we'd no longer be SVR4 abi compliant.

Can you explain what doesn't get aligned?  SVR4 always had 16-byte
stack alignment (unlike some other ppc ABIs).

> > Isn't altivec still useful even if you can't pass vectors as
> > arguments?
> 
> sure, but we don't need a flag to do that.

But we do!  We need a flag to tell the compiler _not_ to use altivec
instructions for block copies, for example, on non-altivec chips.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

>>> Why can't varargs and vector arguments be supported under the SVR4
>>> ABI?
>>
>> because things won't be aligned properly.  and if they were,
>> we'd no longer be SVR4 abi compliant.
>
> Can you explain what doesn't get aligned?  SVR4 always had 16-byte
> stack alignment (unlike some other ppc ABIs).

maybe i'm confusing myself here... how about the other ppc abis?
i didn't mean to single svr4 out.

>>> Isn't altivec still useful even if you can't pass vectors as
>>> arguments?
>>
>> sure, but we don't need a flag to do that.
>
> But we do!  We need a flag to tell the compiler _not_ to use altivec
> instructions for block copies, for example, on non-altivec chips.

but that's only dependant on -maltivec, not on abi. right?

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Alex Rosenberg]

on 2/27/02 9:39 PM, Aldy Hernandez at aldyh@redhat.com wrote:

>>>> No, don't do that.  I can think of lots of reasons not to.
>>> 
>>> care to share?
>> 
>> You'd be deleting a feature, and worse, you'd be re-using the obvious
>> choice for the option that enables that feature for something
>> different, making it difficult to re-introduce that feature in future.
> 
> a feature that no one would use.
> 
> the same people who would want to link old code, wouldn't be able
> to write code that use varargs, vector arguments, etc, which is
> the reason for -mabi=altivec in the first place.

The case to watch out for is a user enabling AltiVec for one or two source
files in a project, the rest of which don't have it enabled.

It's common for code on Mac OS to have a small portion test for the presence
of AltiVec and then use it if available. I'd imagine that many other
projects on other OSes might want the same capability. (Consider SETI@Home.)

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Kumar Gala]

>> VRSAVE is useful for ABIs which allocate registers in order (ie MacOS)
>> such that one can mark the last used register and save/restore to that
>> point.  Otherwise it seems rather painful to manage/update vrsave in 
>> one's
>> code (for SVR4 style register allocation).
>
> ahh, that wasn't clear from the specs

I'm not sure why its not made more clear.  My guess is that the guys who 
came up with it knew about the register allocation in-order on MacOS and 
the Apple guys know about it and took it for granted.

>> If GCC is managing VRSAVE when -mabi=altivec then I think there should 
>> be
>> another flag to disable the use of VRSAVE.  It tends to be a waste of 
>> time
>> to manage as well as hard to use for determining which regs to save by 
>> the
>> context code.
>
> in which case... you are correct.  we should add a flag to not set 
> vrsave.

That would be good (on LinuxPPC the default should be for vrsave to be 
disabled).  I am not sure how register allocation is handled on 
darwin/MacOS-X ABI.  Maybe one of the Apple guys can pipe up, Stan?  My 
guess would be that it does not differ much from how it is handled on 
MacOS.  (I could be wrong).

- kumar

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Dale Johannesen]

On Wednesday, February 27, 2002, at 07:38 PM, Kumar Gala wrote:
> That would be good (on LinuxPPC the default should be for vrsave to be 
> disabled).  I am not sure how register allocation is handled on 
> darwin/MacOS-X ABI.  Maybe one of the Apple guys can pipe up, Stan?  My 
> guess would be that it does not differ much from how it is handled on 
> MacOS.  (I could be wrong).

The usual lreg/greg algorithms are used; it's not necessarily in any order.
By prologue/epilogue generation time we know which Vregs were used in the 
function.
If needed, the old value of VRsave is saved on the stack and VRsave is 
ORed with
a mask indicating which regs are used in the function.  This must be done 
before
any Vreg is actually used.  At epilogue the old VRsave is restored, and 
this must
be after all Vreg uses.  Interrupt handlers, context switch, etc. are 
responsible
for saving/restoring whichever Vregs are indicated by VRsave, i.e. it is 
expected
to be up to date (or overly conservative) all the time.  When non-Altivec 
code
is running, VRsave will be 0, which means there's no save/restore overhead.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

On Thursday, February 28, 2002, at 02:49  PM, Dale Johannesen wrote:

>
> On Wednesday, February 27, 2002, at 07:38 PM, Kumar Gala wrote:
>> That would be good (on LinuxPPC the default should be for vrsave to be 
>> disabled).  I am not sure how register allocation is handled on 
>> darwin/MacOS-X ABI.  Maybe one of the Apple guys can pipe up, Stan?  
>> My guess would be that it does not differ much from how it is handled 
>> on MacOS.  (I could be wrong).
>
> The usual lreg/greg algorithms are used; it's not necessarily in any 
> order.
> By prologue/epilogue generation time we know which Vregs were used in 
> the function.
> If needed, the old value of VRsave is saved on the stack and VRsave is 
> ORed with
> a mask indicating which regs are used in the function.  This must be 
> done before
> any Vreg is actually used.  At epilogue the old VRsave is restored, and 
> this must
> be after all Vreg uses.  Interrupt handlers, context switch, etc. are 
> responsible
> for saving/restoring whichever Vregs are indicated by VRsave, i.e. it 
> is expected
> to be up to date (or overly conservative) all the time.  When 
> non-Altivec code
> is running, VRsave will be 0, which means there's no save/restore 
> overhead.

in other words, it works exactly the same as for all the other ppc
variants? :-)

>
>
--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Dale Johannesen]

On Wednesday, February 27, 2002, at 09:40 PM, Aldy Hernandez wrote:
> On Thursday, February 28, 2002, at 02:49  PM, Dale Johannesen wrote:
>> On Wednesday, February 27, 2002, at 07:38 PM, Kumar Gala wrote:
>>> That would be good (on LinuxPPC the default should be for vrsave to be 
>>> disabled).  I am not sure how register allocation is handled on darwin/
>>> MacOS-X ABI.  Maybe one of the Apple guys can pipe up, Stan?  My guess 
>>> would be that it does not differ much from how it is handled on MacOS.  
>>> (I could be wrong).
>>
>> The usual lreg/greg algorithms are used; it's not necessarily in any 
>> order.
>> By prologue/epilogue generation time we know which Vregs were used in 
>> the function.
>> If needed, the old value of VRsave is saved on the stack and VRsave is 
>> ORed with
>> a mask indicating which regs are used in the function.  This must be 
>> done before
>> any Vreg is actually used.  At epilogue the old VRsave is restored, and 
>> this must
>> be after all Vreg uses.  Interrupt handlers, context switch, etc. are 
>> responsible
>> for saving/restoring whichever Vregs are indicated by VRsave, i.e. it is 
>> expected
>> to be up to date (or overly conservative) all the time.  When 
>> non-Altivec code
>> is running, VRsave will be 0, which means there's no save/restore 
>> overhead.
>
> in other words, it works exactly the same as for all the other ppc
> variants? :-)

Well, yes, but he did ask.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

Aldy Hernandez <aldyh@redhat.com> writes:

> >> i think -maltivec without the abi changes is there for somebody who
> >> *really* knows what s/he's doing, has everything aligned properly, and
> >> wants to have a function callable from non altivec compiled functions.
> >
> > That would be me! I know what I'm doing, have no intention to pass
> > vector arguments or use varargs.
> 
> how about local variables?  there are some magic alignment rules
> that are keyed off of abi=altivec. ... especially the stack boundary.
> 
> how about vrsave?  surely you need vrsave to be set properly, otherwise
> the OS will not save your vector registers on a context-switch.
> 
> how about the prologue and epilogue?  the altivec registers won't be
> saved/restored unless abi=altivec.

All these indicate bugs that should be fixed.  I expect most of the
bugs are that TARGET_ALTIVEC_ABI was used when it should have been
either TARGET_ALTIVEC or nothing.

> some call used registers being altivec?

If !TARGET_ALTIVEC_ABI, all altivec registers are call-clobbered.

> i guess you could use all global variables, and have the OS
> save/restore all vector registers on a context switch (slooow).
> 
> these are just a few of the things that came up while poking around
> the code (search for TARGET_ALTIVEC_ABI).
> 
> perhaps this needs to be readressed and having -maltivec imply an
> abi change^Wenhancement.  i for one, wouldn't mind getting
> rid of -mabi=altivec, but i believe geoff wanted it that way.

No, -maltivec should not change the ABI.  It should allow using
altivec as much as possible with the current ABI.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Aldy Hernandez]

> All these indicate bugs that should be fixed.  I expect most of the
> bugs are that TARGET_ALTIVEC_ABI was used when it should have been
> either TARGET_ALTIVEC or nothing.

agreed, but...

>> perhaps this needs to be readressed and having -maltivec imply an
>> abi change^Wenhancement.  i for one, wouldn't mind getting
>> rid of -mabi=altivec, but i believe geoff wanted it that way.
>
> No, -maltivec should not change the ABI.  It should allow using
> altivec as much as possible with the current ABI.

why would anyone want to use -maltivec without -mabi=altivec?
i see no use for it, especially now that i'm planning on adding
-mno-vrsave as kumar suggested.

--
Aldy Hernandez                                E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Thu, 28 Feb 2002 13:28:15 +1100
> Cc: gcc@gcc.gnu.org
> From: Aldy Hernandez <aldyh@redhat.com>
> X-OriginalArrivalTime: 28 Feb 2002 02:27:40.0116 (UTC) FILETIME=[7E646940:01C1BFFF]
> 
> > All these indicate bugs that should be fixed.  I expect most of the
> > bugs are that TARGET_ALTIVEC_ABI was used when it should have been
> > either TARGET_ALTIVEC or nothing.
> 
> agreed, but...
> 
> >> perhaps this needs to be readressed and having -maltivec imply an
> >> abi change^Wenhancement.  i for one, wouldn't mind getting
> >> rid of -mabi=altivec, but i believe geoff wanted it that way.
> >
> > No, -maltivec should not change the ABI.  It should allow using
> > altivec as much as possible with the current ABI.
> 
> why would anyone want to use -maltivec without -mabi=altivec?
> i see no use for it, especially now that i'm planning on adding
> -mno-vrsave as kumar suggested.

Because they want to link to code that uses the old ABI?

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Don, 2002-02-28 um 00.27 schrieb Aldy Hernandez:

> how about local variables?  there are some magic alignment rules
> that are keyed off of abi=altivec. ... especially the stack boundary.

Local vector variables on stack in a three liner? With 32 registers that
should be quite unlikely.
 
> how about vrsave?  surely you need vrsave to be set properly, otherwise
> the OS will not save your vector registers on a context-switch.

Don't care. There are no other applications using AltiVec.
 
> how about the prologue and epilogue?  the altivec registers won't be
> saved/restored unless abi=altivec.

Don't need to.

> some call used registers being altivec?

Won't happen.
 
> i guess you could use all global variables, and have the OS
> save/restore all vector registers on a context switch (slooow).

Don't need to be and when I'd be using -mabi=altivec now that I know.

> perhaps this needs to be readressed and having -maltivec imply an
> abi change^Wenhancement.  i for one, wouldn't mind getting
> rid of -mabi=altivec, but i believe geoff wanted it that way.

I just wanted to point out that the generated code doesn't seem
to be right when used without that mystic switch and in my
opinion it should be. I don't need any of the spiffy features like
vector arguments, varargs, vectors on stack, vectors used by callers
in this special case.

-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[David Edelsohn]

>>>>> Aldy Hernandez writes:

Aldy> it's a bit tricky.  i don't see any way of altivec working without
Aldy> -mabi=altivec, but we couldn't just blindly modify the abi just because
Aldy> we had altivec enabled, so we had to add another flag.

Aldy> i think -maltivec without the abi changes is there for somebody who
Aldy> *really* knows what s/he's doing, has everything aligned properly, and
Aldy> wants to have a function callable from non altivec compiled functions.

	It is there for the same reason that -mpower and -mpower2 and
-mpowerpc and -mpowerpc-gpopt and -mpowerpc-gfxopt exist.  These are
individual features in the GCC port for this architecture.  For correct
operation they are suppose to be manipulated in concert.  The intent is
that the user implicitly access them with -mcpu=power, -mcpu=power2,
-mcpu=powerpc, -mcpu=604e, etc.  If you try to enable individual options
and don't know what you are doing, use at your own risk.

	For instance, if your default configuration is POWER architecture
and you invoke "gcc -mpowerpc" thinking it is like the old x86 -m486
option, you will get the *union* of the POWER and PowerPC instructions.
On a PowerPC system, all of the POWER instructions will trap and be
emulated by the OS, which probably is not what you wanted.  If you want
to compiler for a PowerPC chip, use -mcpu=powerpc.  Using the wrong
options, at best you will not get peak performance, at worst the program
will crash with an illegal instruction.

David

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Richard Henderson]

On Wed, Feb 27, 2002 at 07:10:38PM -0500, David Edelsohn wrote:
> If you try to enable individual options
> and don't know what you are doing, use at your own risk.

Which suggests either removing the options or naming
them -mdebug-power etc.


r~

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

Richard Henderson <rth@redhat.com> writes:

> On Wed, Feb 27, 2002 at 07:10:38PM -0500, David Edelsohn wrote:
> > If you try to enable individual options
> > and don't know what you are doing, use at your own risk.
> 
> Which suggests either removing the options or naming
> them -mdebug-power etc.

David's comment applies to every option that GCC has; there's no need
to go around renaming -funroll-all-loops to -fdebug-unroll-all-loops
just because it's sometimes ineffective or dangerous.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Richard Henderson]

On Wed, Feb 27, 2002 at 05:43:23PM -0800, Geoff Keating wrote:
> David's comment applies to every option that GCC has; there's no need
> to go around renaming -funroll-all-loops to -fdebug-unroll-all-loops
> just because it's sometimes ineffective or dangerous.

No, if -funroll-all-loops crashes or produces incorrect code, you
report it as a compiler bug, and it may eventually get fixed.

If -mpowerpc produces "incorrect" code, you get told that you
don't know what you're doing.  So why have options with such
tantilizing names?


r~

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

Richard Henderson <rth@redhat.com> writes:

> On Wed, Feb 27, 2002 at 05:43:23PM -0800, Geoff Keating wrote:
> > David's comment applies to every option that GCC has; there's no need
> > to go around renaming -funroll-all-loops to -fdebug-unroll-all-loops
> > just because it's sometimes ineffective or dangerous.
> 
> No, if -funroll-all-loops crashes or produces incorrect code, you
> report it as a compiler bug, and it may eventually get fixed.
> 
> If -mpowerpc produces "incorrect" code, you get told that you
> don't know what you're doing.  So why have options with such
> tantilizing names?

It doesn't produce "incorrect" code, so far as I know, it just doesn't
do what some people might think it would do, and often not what they
want to do either :-).  The problem is that the option name is too
short, really; it should be -menable-powerpc-instructions or something.

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Richard Henderson]

On Wed, Feb 27, 2002 at 06:20:53PM -0800, Geoff Keating wrote:
> It doesn't produce "incorrect" code, so far as I know, it just doesn't
> do what some people might think it would do, and often not what they
> want to do either :-).

Thus incorrect in quotes.

> The problem is that the option name is too
> short, really; it should be -menable-powerpc-instructions or something.

My point exactly.


r~

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Geoff Keating]

> Date: Thu, 28 Feb 2002 00:04:33 -0800
> From: Richard Henderson <rth@redhat.com>

> On Wed, Feb 27, 2002 at 06:20:53PM -0800, Geoff Keating wrote:
> > It doesn't produce "incorrect" code, so far as I know, it just doesn't
> > do what some people might think it would do, and often not what they
> > want to do either :-).
> 
> Thus incorrect in quotes.
> 
> > The problem is that the option name is too
> > short, really; it should be -menable-powerpc-instructions or something.
> 
> My point exactly.

My plan for this is to split the PPC ISA/ABI options up into two
groups, the ones that change the ISA and the ones that change the
ABI; then combine them into just two options, one for each group.

For instance, to specify that you want to compile for a generic
powerpc processor with no FPU, you would write

-misa=generic-powerpc,soft-float
-mabi=svr4,soft-float

to specify that you wish to compile for 64-bit AIX, you would write

-mabi=aix64

to specify that you wish to compile for 64-bit AIX, on a POWER4
processor, using the "graphics extensions", you would write

-mabi=aix64
-misa=power4,gfxopt

To specify that you wish to build for linux, use altivec instructions
but not the altivec ABI, and tune for a ppc750, you would write

-misa=generic-powerpc,altivec
-mabi=svr4
-mtune=750

if you wanted to use the altivec ABI, you would write instead

-misa=generic-powerpc,altivec
-mabi=svr4,altivec
-mtune=750

If you wanted to use all the instructions available on a powerpc 7500,
which includes altivec and some other stuff, you would write instead

-misa=ppc7500
-mabi=svr4,altivec

The same thing without any altivec:

-misa=ppc7500,no-altivec
-mabi=svr4

The first element in the 'isa' and 'abi' options specifies a base
ISA/ABI, the remaining options specify add-ons.

If you specify an invalid combination, say you write

-misa=generic-powerpc,soft-float

but you don't specify a change of ABI, that's a hard error and
compilation stops with a helpful error message ("cannot implement SVR4
ABI without floating-point instructions, try -mabi=...,soft-float").

Anyway, this is what I hope to do when I get time.  It would
completely replace the existing ISA and ABI selection options (maybe
with some compatibility left for the more commonly-used ones).  It
should make it much much harder for users to get confused.

If I get some real time, the options may get called -fisa and -fabi
and this could be implemented for all ports.  Would that be
interesting for everyone?

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

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Mark Mitchell]

--On Wednesday, February 27, 2002 05:43:23 PM -0800 Geoff Keating 
<geoffk@geoffk.org> wrote:

> Richard Henderson <rth@redhat.com> writes:
>
>> On Wed, Feb 27, 2002 at 07:10:38PM -0500, David Edelsohn wrote:
>> > If you try to enable individual options
>> > and don't know what you are doing, use at your own risk.
>>
>> Which suggests either removing the options or naming
>> them -mdebug-power etc.
>
> David's comment applies to every option that GCC has; there's no need
> to go around renaming -funroll-all-loops to -fdebug-unroll-all-loops
> just because it's sometimes ineffective or dangerous.

But if I had my way that option, and many other optimization knobs,
would not exist at all in released versions of GCC!

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Daniel Egger]

Am Mit, 2002-02-27 um 05.52 schrieb Aldy Hernandez:

> first, you can't possibly do -maltivec and not do -mabi=altivec.
> who knows what will happen.

Ayiee. Why does -maltivec not imply -mabi=altivec then?
All I can tell is that it worked so far except for the posted
example which I will have to reiterate now.
 
> second, it would probably better if you configured with --enable-altivec.
> did you do that?  if so, you don't need to pass -maltivec or
> -mabi=altivec.

No, I didn't.

-- 
Servus,
       Daniel

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[Robert Dewar]

<<If -mpowerpc produces "incorrect" code, you get told that you
don't know what you're doing.  So why have options with such
tantilizing names?
>>

i see nothing tantalizing about the name, this seems a weak and
unconvincing argument.

Re: [TESTCASE] Minimized testcase for AltiVec segfault

[mike stump]

> Date: Wed, 27 Feb 2002 22:58:57 -0800
> From: Mark Mitchell <mark@codesourcery.com>
> To: Geoff Keating <geoffk@geoffk.org>, Richard Henderson <rth@redhat.com>
> cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> > David's comment applies to every option that GCC has; there's no need
> > to go around renaming -funroll-all-loops to -fdebug-unroll-all-loops
> > just because it's sometimes ineffective or dangerous.

> But if I had my way that option, and many other optimization knobs,
> would not exist at all in released versions of GCC!

It would be great if someone fixed all the important outstanding
deficiencies with -funroll-all-loops and made it the default and
removed the option.  :-)