Altivec Context Management

[Ralf Corsepius]

On Fri, 2005-11-04 at 10:25 -0600, Joel Sherrill  wrote:
> Ralf Corsepius wrote:
> > On Fri, 2005-11-04 at 08:16 -0600, Joel Sherrill  wrote:
> > 
> > 
> >>+ Add Altivec multilib
> >>
> >>   If we have extra registers which gcc is aware of, this forces our hand
> >>   and it adds a multilib.
> > 
> > We already have this multilib.
> > 
> > -mcpu=7400 implies altivec, all others don't.
> 
> Sorry I missed that piece of knowledge.

The magic is deeply hidden in GCC's sources:

Check gcc-4.0.x/gcc/config/rs6000/rs6000.c for POWERPC_7400_MASK.

>   Then RTEMS should just honor 
> the __ALTIVEC__ flag which is set when -mcpu=7400 is set.  It will 
> require no tool changes for gcc 4.0.x.
> 
> The gcc version for 4.6 does not set __ALTIVEC__ when -mcpu=7400 is 
> specified.

I current don't have such a toolchain at hand, but if I recall
correctly, it didn't have an -mcpu=7400 multilib variant ;)

Checking GCC-3.4's source code however indicates that -mcpu=7400 already
implied -maltivec and -D__ALTIVEC__ in gcc-3.4. This matches with my
memory, because I believe altivec had been introduced in gcc-3.4 and
then more or less completely rewritten for gcc-4.x).

> > I.e. if -maltivec is a problem to RTEMS and some BSPs, you should use a
> > different -mcpu=<cpu>. If this is not possible, the powerpc port in
> > RTEMS is facing a the limitations of its design.
> 
> > IMO, a separate -maltivec multilib variant doesn't make without a major
> > redesign of the powerpc port. 
> 
> It doesn't sound like the multilib variant is needed as long as 
> -mcpu=7400 is really the correct CPU model CFLAG for the BSPs/CPU models 
> in question.
It's the old problem with powerpc port:
powerpc-RTEMS classifies its internals on "cpu-variants", while GCC is
on the move towards classifying its internals on "cpu-features".

> But RTEMS does need to honor the __ALTIVEC__ flag and based upon gcc's 
> use of the vector registers, this would mean it is part of the basic 
> integer context when available.

I recall we had a discussion on this topic when gcc-4.0 ca. at the time
when about to be released or just released. The result of this
discussion was to add an m7400 multilib variant.

> >>   Whether this should be done for 4.6 tools is up for discussion but it
> >>   is clear that gcc 4.0.x and newer definitely will have to ship with
> >>   Altivec multilibs for RTEMS.
> > 
> > 
> > cf. above.
> 
> They already do.  RTEMS itself just needs to honor Altivec.
> 
> Good.. one less piece to deal with.
That's at least how I understand this issue (but I am not a powerpc
expert). 

BTW: Check gcc-4.0.x/gcc/config/rs6000/rs6000.c for OS_MISSING_ALTIVEC.
I didn't try to investigate what it actually is, but it's looks like it
probably related to the RTEMS altivec problem

Ralf