This is the mail archive of the 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: A Far Less Ambitous AltiVec patch

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

! 	fprintf (file, "%d", REGNO (XEXP (x, 0)));

      case 'q':
--- 8960,8966 ----
  	  || REGNO (XEXP (x, 0)) >= 32)
  	output_operand_lossage ("invalid %%P value");
! 	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

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