This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: altivec questions
On Wed, Jun 30, 2004 at 03:45:59PM -0700, Ziemowit Laski wrote:
>
> On 29 Jun 2004, at 13.58, Janis Johnson wrote:
>
> >Some AltiVec observations and questions:
> >
> >1. vector bool
> >
> > The documentation says "The bool type is deprecated and will be
> > discontinued in future revisions. Use vector signed instead."
>
> That's a bug in the documentation. 'vector bool ...' types are
> first-class
> citizens which _must_ be kept distinct from 'vector signed ...' or
> 'vector unsigned ...'.
That's how it was originally documented, but now they are first-class
citizens and ought to be documented as such.
> > Recently, though, Zem added lots of support for vector bool and
> > except for some apparent oversights it appears to be fully supported
> > now, along with vector pixel.
>
> Indeed. What are the oversights? :-) I wouldn't mind fixing them,
> unless
> you have done so in the work you mention below.
Yeah, I've done the work; it's coming as soon as I figure out how to
break up the one massive patch into smaller ones, and finish testing.
> >
> >2. vector long types
> >
> > Use of "vector signed long" and "vector unsigned long" isn't
> > documented, but GCC gives "warning: use of 'long' in AltiVec types
> > is deprecated; use 'int'". These ought to be hard errors for -m64,
> > right?
>
> Why?
For 32-bit code generation 'vector long' is treated the same as
'vector int', which makes sense when 'long' is the same length as
'int'. It doesn't make sense, however, when long is 64 bits.
Currently there are just mysterious failures, which I can't remember
at the moment.
> >
> >3. pointers to long and unsigned long
> >
> > Several tests pass 'long *' or 'unsigned long *' in places where the
> > Motorola AltiVec PIM does not include those types among the
> > acceptable arguments. GCC doesn't complain for either -m32 or -m64.
> > These ought to be errors for -m64, right?
>
> Yes, I think they probably should.
I'll look into fixing this where the builtins are handled in rs6000.c.
> > Should GCC's altivec.h
> > support the ones that are used in the gcc.dg/vmx tests?
> >
> >I've gone through the Motorola AltiVec PIM and altivec.h comparing the
> >generic and specific AltiVec operations with the C++ functions and the
> >C macros. I'm sure these matched up when Aldy was finished, but there
> >are a lot of inconsistencies since the addition of support for vector
> >bool and vector pixel. I'm testing a big patch to altivec.h that makes
> >everything match again, and I'll have a patch to extend.texi to make
> >the
> >documentation match what's supported in altivec.h. Before I submit
> >these I'd like to clear up the questions above and make sure I'm
> >understanding this stuff correctly.
>
> Great; thanks. Please also take a look at the apple-ppc-branch (which
> both
> IBM and Apple are currently working on); it is possible that it
> contains some
> of the fixes you are looking for.
Thanks, I'll do that. Is that branch expected to work for GNU/Linux?
I was hoping to try it but it doesn't build.
Janis