Bug#304089: [PPC] Enable -mvrsave=yes by default

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 11, 2005 at 08:59:38PM +0300, Konstantinos Margaritis wrote:
> On ?????????????? 10 ???????????????? 2005 23:32, Matthias Klose wrote:
> > Konstantinos Margaritis writes:
> > > Package: gcc-3.4
> > > Version: 3.4.3-12
> > > Severity: grave
> > >
> > > Apparently latest packages of gcc-3.4 have disabled -mvrsave=yes
> > > for powerpc. This breaks existing software which uses Altivec and
> > > it's also wrong. Even worse, it's not documented in the changelog
> > > (Debian or normal). The code that is produced is unstable. Please
> > > enable it by default.
> >
> > which Debian version did have the old behaviour?
> 
> Well, gcc 3.3 has -mvrsave=yes by default and also _I think_ the 
> previous version of gcc i used (3.4.3-6) . It was after the upgrade 
> to -12 that I noticed some strange behaviour in my programs and it 
> was just then that I checked and found after a lot of frustration 
> that it's turned off. I have discussed this with other powerpc 
> developers (though on irc only, i don't have anything in email, and 
> not only Debian developers) and they all confirm that this is a wrong 
> and confusing move. At the very least it should post a warning when 
> it finds altivec code, that -mvrsave is disabled. I don't deny that 
> there are a few cases where the developer might want to leave it 
> disabled, but these are the exceptions not the norm.
> 
> Please, reenable it, or at the very least put a warning and some entry 
> in the changelog about this. It's truly too dangerous to leave it 
> like that.

How odd.  Matthias, I can reproduce this in 3.3.4-13, but not in
3.4.3-7.  Compile this (crappy) testcase with -O2 -maltivec
-mabi=altivec, and with -mvrsave=yes/-mvrsave=no:

#include <altivec.h>

void bar();
vector int ret();
void arg(vector int, ...);

int foo()
{
  vector int q = ret(), t = ret(), z, a, b, c, d, e, f, g, h;
  z = vec_add (q, t);
  a = vec_add (z, t);
  b = vec_add (a, t);
  c = vec_add (b, t);
  d = vec_add (c, t);
  e = vec_add (d, t);
  f = vec_add (e, c);
  g = vec_add (f, t);
  h = vec_add (g, z);
  bar ();
  z = vec_add (h, vec_add (z, t));
  arg (z, a, b, d, h);
}


Konstantinos, I strongly suspect this was a bug in GCC 3.3.  The Linux
kernel does not pay attention to vrsave in 32-bit mode:

         * If the previous thread used altivec in the last quantum
         * (thus changing altivec regs) then save them.
         * We used to check the VRSAVE register but not all apps
         * set it, so we don't rely on it now (and in fact we need
         * to save & restore VSCR even if VRSAVE == 0).  -- paulus

So if you insist that GCC needs to fiddle the register, when nothing is
looking at it, you'll need some better reason why.

-- 
Daniel Jacobowitz
CodeSourcery, LLC