[Bug target/34526] New: no-altivec ABI should be fixed or no longer be the default

[Bug target/34526] New: no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

This PR is meant to be a central place to record information about this issue.

The default ABI for 32-bit PowerPC GNU/Linux does not pass vectors in AltiVec
registers and does not save and restore AltiVec registers in functions that use
those registers.  With -mabi=altivec, vectors are passed in AltiVec registers
and AltiVec registers used within a function are saved and restored.  This has
always been a problem if multiple functions in a call chain use AltiVec
registers without the AltiVec ABI, but it's become a more visible issue with
-ftree-vectorize included in -O3, particularly when the user specifies a CPU
that supports AltiVec and might not realize that those two options imply that
AltiVec registers will likely be used in multiple functions in a call stack
without saving and restoring them.

Two recent PRs that are due to this problem are 34038 and 34437.  A
somewhat-rel
ated PR is 33899.

There were some recent discussions of this issue:

  http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02159.html
  http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html

This ought to be fixed either by using the AltiVec ABI by default or by
changing the non-AltiVec ABI to save and restore AltiVec registers in functions
that use them.


-- 
           Summary: no-altivec ABI should be fixed or no longer be the
                    default
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #1 from janis at gcc dot gnu dot org  2007-12-19 18:50 -------
I'd like to see -mabi=altivec be the default for -m32, with -mabi=no-altivec
available for the rare cases when it's needed.  Would changing the default
cause any problems?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-25 23:17:03
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #2 from janis at gcc dot gnu dot org  2008-01-25 23:19 -------
I'm planning to write and test a patch to change the default ABI to be the
AltiVec ABI.  I don't anticipate, though, that any issues would be found with
the GCC testsuite; any problems would be due to compatibility issues in the
real world.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #3 from janis at gcc dot gnu dot org  2008-01-29 23:45 -------
While testing an extremely simple patch for this PR I discovered that
-mabi=no-altivec hasn't had an effect since r99284, which changed the way that
options are handled for the rs6000 back end.  Before that change,
rs6000_override_options set rs6000_altivec_abi to the appropriate default
before calling rs6000_parse_abi_options, which could change rs6000_altivec_abi.
 After that revision the -mabi option is handled _before_ the call to
rs6000_override_options.

I'm now searching for the appropriate place to set the _default_, not
_override_, for rs6000_altivec_abi.  Hints gratefully accepted.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #4 from janis at gcc dot gnu dot org  2008-01-30 01:34 -------
TARGET_ALTIVEC_VRSAVE is also set to one in rs6000_override_options after
-mno-vrsave has been process, meaning that the option has no effect.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #5 from janis at gcc dot gnu dot org  2008-02-04 21:28 -------
A prerequisite to changing the default to the AltiVec ABI is to fix
-mabi=no-altivec.  A patch for that is at 

  http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #6 from janis at gcc dot gnu dot org  2008-02-05 02:23 -------
There's another mess hiding under the ABI change, which is that synthetic
vectors of the same size as AltiVec vectors are passed differently for
-mabi=altivec than for -mabi=no-altivec.  There are warnings for synthetic
vectors passed by reference with "-mno-altivec -mabi=no-altivec" (currently the
-m32 default) but no warning for "-mno-altivec -mabi=altivec" (the planned -m32
default).  Varargs are apparently broken for "-mno-altivec -mabi=altivec", or
at least test gcc.c-torture/execute/va-arg-25.c fails with those options as the
default.

I wonder if anything actually uses synthetic vectors and if so, whether they
are ever passed as arguments or return values.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[drow at gcc dot gnu dot org]

------- Comment #7 from drow at gcc dot gnu dot org  2008-02-05 03:19 -------
Subject: Re:  no-altivec ABI should be fixed or no longer
        be the default

On Tue, Feb 05, 2008 at 02:23:20AM -0000, janis at gcc dot gnu dot org wrote:
> There's another mess hiding under the ABI change, which is that synthetic
> vectors of the same size as AltiVec vectors are passed differently for
> -mabi=altivec than for -mabi=no-altivec.

FYI, this is target/33899.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #8 from janis at gcc dot gnu dot org  2008-02-07 02:04 -------
Some experimentation shows how GCC is passing and returning non-hardware
vectors for powerpc*-linux:

-m32 (for trunk and 4.0)
  pass struct by reference (copy in caller's frame)
  return struct in memory using address in hidden first argument

  -mno-altivec -mabi=no-altivec         pass vector argument by reference
  -mno-altivec -mabi=no-altivec         return vector result via hidden arg 1

  -maltivec -mabi=no-altivec            pass vector argument by reference
  -maltivec -mabi=no-altivec            return vector result in r3-r6

  -mno-altivec -mabi=altivec            pass vector argument in caller's frame
  -mno-altivec -mabi=altivec            return vector result in r3-r6


-m64
  pass struct in argument registers
  return struct in memory using address in hidden first argument

  -mno-altivec -mabi=altivec            pass vector argument in caller's frame
  -mno-altivec -mabi=altivec            return vector result in r3-r4

  [processing -mabi=no-altivec has been broken since 4.1]

-m64 with 4.0
  -mno-altivec -mabi=no-altivec         pass vector argument by reference
  -mno-altivec -mabi=no-altivec         return vector result via hidden arg 1

  -maltivec -mabi=no-altivec            pass vector argument by reference
  -maltivec -mabi=no-altivec            return vector result via hidden arg 1

  -mno-altivec -mabi=altivec            pass vector argument in caller's frame
  -mno-altivec -mabi=altivec            return vector result in r3-r4

This is a mess.  I'd like to change the -m32 behavior to pass non-hardware
vectors by reference and to return them via a pointer in the hidden first
argument.  For -m64 I'd return them via a pointer in the hidden first argument,
but I'm not sure whether to pass them by reference, or in argument registers
like aggregates.  Suggestions?


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #9 from janis at gcc dot gnu dot org  2008-02-07 18:21 -------
I talked to Steve Munroe about the ABI issues.  We determined that for
powerpc*-linux, vector types that cannot be passed in vector registers should
be passed as aggregates according to the relevant ABI (32-bit or 64-bit PowerPC
ELF).  I'll re-enable -mabi=no-altivec in a way that doesn't break SPE, fix the
argument/result passing mess, and then switch the default to -mabi=altivec for
-m32, as separate patches.


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #10 from janis at gcc dot gnu dot org  2008-02-12 01:35 -------
I'm still plugging away at this since I keep thinking of more things I might
have broken.  I've got some good new tests for the testsuite now that check how
arguments and return values are actually passed for powerpc64-linux -m32 and
-m64.  I also have little tests, not for the testsuite, to check that I haven't
broken argument and return passing for AIX and Darwin by comparing generated
assembly with and without my patch.  For those I've only tried 32-bit code and
need to find out how to configure to build a cross cc1 for 64-bit code.  There
are lots of other powerpc targets I'd like to check; any suggestions for target
triples for which to build cross cc1?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[drow at gcc dot gnu dot org]

------- Comment #11 from drow at gcc dot gnu dot org  2008-02-14 16:31 -------
Might want to try at least one SPE target, for completeness.  I think
powerpc-*-eabispe is sim testable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #12 from janis at gcc dot gnu dot org  2008-02-22 01:56 -------
Subject: Bug 34526

Author: janis
Date: Fri Feb 22 01:55:40 2008
New Revision: 132537

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132537
Log:
        PR target/34526
        * config/rs6000/rs6000.c (rs6000_altivec_abi): Clarify comment.
        (rs6000_explicit_options): Split abi into spe_abi and altivec_abi,
        add vrsave.
        (rs6000_override_options): Set altivec_abi as default, not override,
        for 64-bit GNU/Linux; for 32-bit GNU/Linux default to altivec_abi for
        TARGET_ALTIVEC; default to TARGET_ALTIVEC_VRSAVE when AltiVec ABI
        is used; use new member spe_abi.
        (rs6000_handle_option): Set rs6000_explicit_options.vrsave; use
        spe_abi and altivec_abi.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #13 from janis at gcc dot gnu dot org  2008-02-22 01:58 -------
Subject: Bug 34526

Author: janis
Date: Fri Feb 22 01:57:56 2008
New Revision: 132538

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132538
Log:
        PR target/34526
        * config/rs6000/rs6000.c (rs6000_altivec_abi): Clarify comment.
        (rs6000_explicit_options): Split abi into spe_abi and altivec_abi,
        add vrsave.
        (rs6000_override_options): Set altivec_abi as default, not override,
        for 64-bit GNU/Linux; for 32-bit GNU/Linux default to altivec_abi for
        TARGET_ALTIVEC; default to TARGET_ALTIVEC_VRSAVE when AltiVec ABI
        is used; use new member spe_abi.
        (rs6000_handle_option): Set rs6000_explicit_options.vrsave; use
        spe_abi and altivec_abi.

Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[bje at gcc dot gnu dot org]

------- Comment #14 from bje at gcc dot gnu dot org  2009-05-14 05:34 -------
Can this PR be closed now, Janis?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

------- Comment #15 from janis at gcc dot gnu dot org  2009-05-14 16:50 -------
Fixed by the patches shown in comments 12 and 13.


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526