Re: A Far Less Ambitous AltiVec patch

[Aldy Hernandez <aldyh at redhat dot com>]

[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.

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 ;-):

 > +   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 never reported regression results.  Segher also said he would test
on ppc64-linux, but I haven't heard from him either.

 >   /* "... 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?

 >         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.

 > + /* 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 ;-)).  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.

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