PPC CFLAGS [Was: Re: rpms/openarena/devel openarena.spec, 1.1, 1.2]

[Dan Williams]

On Fri, 2007-01-12 at 15:24 +0100, Ralf Corsepius wrote: 
> On Fri, 2007-01-12 at 21:29 +0800, David Woodhouse wrote:
> > On Fri, 2007-01-12 at 14:08 +0100, Axel Thimm wrote:
> > > What is the difference? If a unit has been compiled with altivec and
> > > the resulting binary calls something in this unit on a non-altivec
> > > system your binary will still boom, or not?
> > > 
> > > E.g. if we need to support non-altivec system then altivec must be
> > > strictly banned unless - as you wrote - the software is smart enough
> > > to do it at runtime (which is seldom).
> > 
> > Not _so_ seldom, in Altivec-capable code. Programs like xine and mplayer
> > get it right. There are parts which are compiled with -maltivec but
> > they're conditionally called.
> 
> Conditionally at compile-time or at run-time?
> 
> Normally, packages trying squeeze out cpu-variant specifics apply
> compile-time conditionals. i.e. they break on some cpu-variants at
> run-time (The reason why rtems has an -maltivec multilib ;) ).

Runtime.

Here's how it should work:

1: put all altivec functions in their own execution unit (ie, C file)
2: put the code that _calls_ these altivec functions in another file
3: that other file will need to do CPU ID checks at runtime; if it finds
that it is running on an altivec capable CPU, it calls the
altivec-enabled code from (1)
4: if it finds it is _not_ running on an altivec-enabled CPU, then it
must call slowpath functions that are _not_ compiled with altivec

So you can certain compile some files with altivec; but at runtime you
must _never_, _ever_ unconditionally call any code in those files
without first checking that you are running on an altivec-capable CPU.

Check out the X server code here:

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=tree

specifically, the files "fbpict.c" and "fbmmx.c".  Note the function
fbHaveMMX() at the bottom of fbpict.c.  It returns true if the machine
has MMX.  There are conditional statements throughout the fbpict.c file
that check for MMX, and if so, call a function in 'fbmmx.c' that
contains mmx code.  There is _no_ MMX code in fbpict.c.

if (fbHaveMMX())
    func = fbCompositeSolidMask_nx8x0565mmx;
else
    func = fbCompositeSolidMask_nx8x0565;

[snip]

(*func) (op, pSrc, pMask, pDst,
         x_src, y_src, x_msk, y_msk, x_dst, y_dst,
         w_this, h_this);

_That_ is the correct way to do it.  The
fbCompositeSolidMask_nx8x0565mmx() function is in fbmmx.c, which is
compiled with MMX flags, but never gets unconditionally called at all.
You have to put the stuff that needs the MMX flags in a separate file to
ensure that GDB doesn't insert MMX instructions into functions that you
don't want it too.

Dan

> > > Are there relevant numbers of G3 systems out there that we want to
> > > support (excluding the unreleased G3+altivec chip)?
> > 
> > I don't know about G3 but there are relevant numbers of Altivec-less
> > systems out there, since that includes POWER -- and in particular a
> > bunch of our build machines.
> > 
> > Do not build packages which use Altivec unconditionally -- always make
> > it check at runtime, just as we do for MMX/SSE/etc. 
> OK, that's what I wanted to hear.
> 
> => This package is broken, -maltivec is forbidden.
> 
> Ralf
> 
>