rearrange -mcpu= code for rs6000

Matt Thomas
Fri Sep 26 14:52:00 GMT 2003

On Friday, September 26, 2003, at 07:20 AM, David Edelsohn wrote:

>>>>>> Geoffrey Keating writes:
> Geoff> I don't understand.  How can it be a win for some applications 
> but not
> Geoff> for others?  We're talking about replacing a library routine 
> with an
> Geoff> instruction; surely one or the other will be faster every time.
> 	It can depend on the cache footprint, other uses of the math
> library, etc.

> Geoff> MASK_ALTIVEC is supposed to only control the emission of Altivec
> Geoff> instructions, not any other behaviour.  Presumably if you're 
> using the
> Geoff> processor in an environment where Altivec is unavailable (or 
> where the
> Geoff> FPU is unavailable, or whatever) you'd use -mcpu=xxx 
> -mno-altivec, or
> Geoff> -mcpu=xxx -msoft-float.
> 	That's the fundamental question: which should be the default.
> -mcpu=xxx -maltivec
> to enable Altivec
> or
> -mcpu=xxx -mno-altivec
> to disable Altivec.

As the person for NetBSD who does most of PowerPC support, I'd like
to request that you must explicit specifiy -maltivec to get altivec.
Otherwise, for an example, a naive user who enters -mcpu=7450 when
compiling his kernel will run into a nasty surprise.

Also note that saving/restoring Altivec registers for context switching
takes additional overhead and some implementation might not want that.

> Geoff> I would expect that most or all applications running on an
> Geoff> Altivec-enabled chip will use Altivec anyway; for memcpy(), 
> bzero(),
> Geoff> etc.
> 	Isn't this OS-specific?

It is.

> Geoff> Well, that's what we document it to do, so why should anyone be
> Geoff> surprised to find that is what it actually does?
> 	Where is that documented?  In the FSF GCC documentation or Apple
> GCC documentation?

And how many endusers *really* read documentation?  I think gcc should
act in the manner of least surprise, and that to me is you have to
explicitly enable Altivec.
Matt Thomas                     email:
3am Software Foundry              www:
Cupertino, CA              disclaimer: I avow all knowledge of this 

More information about the Gcc-patches mailing list