This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC/powerpc AltiVec expectations.


Yes, if I understand you correctly, the concept of '#pragma altivec_vrsave
allon' is not supported by how GCC handles vrsave today.

- kumar

On Tue, 2 Jul 2002, Aldy Hernandez wrote:

>
> > >no.  you'll have to use -mvrsave=yes/no, which affects the entire file,
> > >not just one  function.
> >
> > How does that work on a file bases?  When would vrsave get set and
> > cleared?
>
> sorry, let me be clear.
>
> you can't use a pragma to enable/disable vrsave generation for a particular
> function.  you use -mvrsave=yes to enable vrsave generation for all the
> functions in a compilation unit:
>
> 	gcc -maltivec -mabi=altivec -mvrsave=yes foo.c
>
> all code in foo.c will maintain vrsave integrity.
>
> bar()
> {
> 	use v50, v51, v52
> 	hotdog()
> }
>
> right before the call to hotdog(), the corresponding bits for v50-v52
> will be ORed with the bits already in vrsave.  the caller of bar() will
> restore the value of vrsave upon return from bar.
>
> the initial value of vrsave is assumed to be set by the OS.
>
> vrsave generation is on by default in gcc, though since the minority
> OS need it, it should be switched to off.
>
> at least that's how i think it works.  i should know, i wrote it.  but i
> should double check though.
>
> is this clearer?
>
> aldy
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]