Re: A Far Less Ambitous AltiVec patch

[Ziemowit Laski <zlaski at apple dot com>]

On 2 Feb, 2004, at 13.18, Aldy Hernandez wrote:

> [Respective maintainers should comment on the non AltiVec parts.
> Mark/Jason could you at least take a look at the vector mangling code
> Ziemowit wrote?]
>
> > Most of the remaining bits are also Darwin or RS6000-specific.  The 
> > only
> > platform-independent change is the addition of a target hook for
> > mangling of vendor-specific types (which AltiVec types are).  Luckily,
> > no demangler changes are needed.
>
> I am not a big fan of vendor specific manglers, especially if it's
> just for vectors.  We should come up with a generic way of mangling
> vector types in GCC.

Given that our C++ ABI supports vendor-specific _mangling_ (via 'u'
and 'U'), I must say I don't follow your objection to vendor-specific
_manglers_. :-)

The AltiVec mangling produced by my patch has the following 
characteristics:
  (1) It is identical to that produced by Apple's gcc 3.1 and gcc 3.3 
compilers,
      as well as CodeWarrior and MrC.
  (2) It nicely demangles (via c++filt3) to the vector type names (e.g.,
      '__vector unsigned int'), without changes needed in the demangler.

I can't see how a "generic" vector mangler will account for differences
between, e.g, 'vector unsigned short' and 'vector bool short' (which, of
course, your work failed to do throughout :-( ).  Besides, people using
SSE2 or the like would have to buy in on any mangling scheme agreed to.

> Also, if we do agree that vendor specific manglers are the way to go,
> this bit needs to check for the tree actually being a vector.  You
> don't want backends to bypass the entire demangling code with a
> backend specific one ;-):

But why do you assume that vectors will be the only types requiring
vendor-specific mangling?  While it is true in the case of AltiVec, it 
need
not be for other vendor-specific extensions.

> > +   else if ((vendor_type_mangling = 
> > (*targetm.mangle_vendor_type)(type)))
> > +     {
> > +       write_string (vendor_type_mangling);
> > +       return;
> > +     }
>
> There is no documentation for mangle_vendor_type.

You mean in mangle.c itself?  OK, I'll put it in.
> You never reported regression results.  Segher also said he would test
> on ppc64-linux, but I haven't heard from him either.

Well, no, I didn't bother, suspecting that some time will elapse between
my posting of the patch and another human reviewing it.  I have, of 
course,
been vindicated. :-)

> >   /* "... and so I think no man in a century will suffer as greatly as
> >      you will."  */
>
> Well, if we're going to keep it, might as well move it to the context
> in which it belongs :-).  Move it right after:
>
> ! #else /* not C++ */
>
> Timing is everything...
>
>
> > + /* The "-faltivec" option should have been called "-maltivec" all 
> > along.  */
> > + #define SUBTARGET_OPTION_TRANSLATE_TABLE				\
> > +   { "-faltivec", "-maltivec -include altivec.h" },	\
> > +   { "-fno-altivec", "-mno-altivec" },	\
>
> Do we really need another option (even if just for Darwin)?  This is
> just plain sick.  Can't you make -maltivec include altivec.h just for
> darwin?

The '-faltivec' option is part of Apple AltiVec folklore as much as the
C++ mangling.

> >         else
> > ! 	fprintf (file, "%d", REGNO (XEXP (x, 0)));
> >         return;
>
> >       case 'q':
> > --- 8960,8966 ----
> >   	  || REGNO (XEXP (x, 0)) >= 32)
> >   	output_operand_lossage ("invalid %%P value");
> >         else
> > ! 	fprintf (file, "%s", reg_names[REGNO (XEXP (x, 0))]);
>
> Uhh, what in the world is this?  I thought all assemblers were
> supposed to support plain reg numbers.

Obviously then, you did not even go near Darwin when testing your
original AldyVec work. :-)  The Darwin assembler requires register
operands to be encoded as such (and for a very good reason, IMHO).

> > + /* Handle the "altivec" attribute.  The attribute may have
> > +    arguments as follows:
>
> *Sigh*.  I really hate this, but I see no better way to actually
>  implementing so I guess it's ok.
>
> Assuming you made no cut-n-paste errors... The altivec.h changes,
> which are the bulk of your changes look good so far.  I would like to
> see testresults for ppc64 (Segher?), darwin, and a ppc32 target that
> uses altivec but isn't darwin (ahem ppc-linux ;-)).

I'll check if we have YDL installed somewhere, but I'm assuming that
_you_ do? :-)

>  Ideally, but I
> won't make you do this (unless you really want to be a sport
> (please)), run the altivec testsuite I know y'all have.

Our internal testsuite utilizes Motorola syntax, so that's a no-go
and you know it. :-)

> Do you mind addressing what I mentioned, testing, and reposting with
> -u (not -cp), and please take out the vendor_type_mangling thing out
> until the C++ folks chime in.


> Cheers.
> Aldy
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477