This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC/powerpc AltiVec expectations.
- From: Kumar Gala <kumar dot gala at motorola dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Kumar Gala <Kumar dot Gala at motorola dot com>, Matt Thomas <matt at 3am-software dot com>, Geoff Keating <geoffk at geoffk dot org>, <gcc at gcc dot gnu dot org>
- Date: Tue, 2 Jul 2002 10:45:36 -0500 (CDT)
- Subject: 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
>