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: PATCH: New hook for custom-mangling of C++ scalars

On 20 Mar 2004, at 18.31, Zack Weinberg wrote:

Ziemowit Laski <> writes:

This is yet another fallout from my earlier AltiVec activity.
Initially, I had a hook for custom-mangling of entire VECTOR_TYPEs,
but Mark convinced me to custom-handle only the elements of vectors.
So here goes.

Bootstrapped, with no regressions. OK to commit?

This is OK in principle but I must ask for a few revisions:

+  /* Return a vendor-specific C++ mangling for TYPE, or NULL if
+     default C++ mangling for TYPE should be used instead.  Only


+      /* Enable AltiVec-specific name-mangling.  */
+      targetm.mangle_scalar_type = rs6000_mangle_scalar_type;

This should be handled with an #undef and #define in rs6000.c, like any other target hook. That then permits you to make rs6000_mangle_scalar_type static in rs6000.c. (The types in question are never used unless Altivec is enabled, so there is no need to turn the hook off when Altivec is disabled.)

Ok. (I was just being paranoid about performance in the non-AltiVec case.)

+  if (type == bool_char_type_node) return "U6__boolc";
+  if (type == bool_short_type_node) return "U6__bools";
+  if (type == pixel_type_node) return "u7__pixel";
+  if (type == bool_int_type_node) return "U6__booli";

Encoding "bool X" as a "vendor-extended type qualifier" is a little weird, IMHO, but I don't have a problem with it. They demangle to "<type> __bool" (owing to the weird C++ convention of writing type qualifiers after the base type, contrary to English, but never mind) -- the only way this is relevant to you is, the C++ parser had better accept "int __bool" as well as "__bool int".

Yes, 'int __bool' is an allowable variant of '__bool int'; however, the types demangle to '__bool <type>' rather than '<type> __bool':

00000048 T foo(__vector __bool char)
00000120 T foo(__vector __bool int)
000000b4 T foo(__vector __bool short)
00000024 T foo(__vector signed char)
00000144 T foo(__vector float)
00000000 T foo(__vector unsigned char)
000000fc T foo(__vector int)
000000d8 T foo(__vector unsigned)
00000090 T foo(__vector short)
0000006c T foo(__vector unsigned short)
00000168 T foo(__vector __pixel)
000001c4 T foo(float)
0000018c T foo(int)
000001a8 T foo(unsigned)

@@ -1468,6 +1469,7 @@ write_type (tree type)
    /* This gets set to nonzero if TYPE turns out to be a (possibly
       CV-qualified) builtin type.  */
    int is_builtin_type = 0;
+  const char *vendor_scalar_mangling;

MANGLE_TRACE_TREE ("type", type);

@@ -1501,6 +1503,13 @@ write_type (tree type)
         case BOOLEAN_TYPE:
         case INTEGER_TYPE:  /* Includes wchar_t.  */
         case REAL_TYPE:
+         /* Handle any target-specific scalar types.  */
+         if ((vendor_scalar_mangling =
+           {
+             write_string (vendor_scalar_mangling);
+             return;
+           }

Write this like this:

          case BOOLEAN_TYPE:
          case INTEGER_TYPE:  /* Includes wchar_t.  */
          case REAL_TYPE:
            /* Handle any target-specific scalar types.  */
            const char *target_mangling
              = targetm.mangle_scalar_type (type);
            if (target_mangling)
                write_string (target_mangling);
          /* otherwise... */

Indeed, your approach is a lot cleaner.

+@deftypefn {Target Hook} const char * TARGET_MANGLE_SCALAR_TYPE (tree
+This target hook should return a string denoting a vendor-specific C++
+mangling for the given scalar @var{type}. Only vendor-specific scalar
+types should have vendor-specific manglings supplied for them. For all
+other scalar types (including built-in types such as @code{int} or
+@code{float}), the target hook should return @code{NULL}, indicating
+the default C++ mangling scheme should be used. The default target
+will return @code{NULL} for all values of @var{type}. This target hook
+will not be used for non-scalar types.
+@end deftypefn

Needs a rewrite, mainly because the encoding for these types is defined by the C++ ABI and therefore should be documented. Also, need to make clear that the target hook is expected to return a pointer to static memory. Suggest:

@deftypefn {Target Hook} {const char *} TARGET_MANGLE_SCALAR_TYPE (tree @var{type})
If your target defines any extended scalar types, define this hook to
return the appropriate encoding for these types as part of a C++
mangled name. The @var{type} argument is the tree structure
representing the type to be mangled. The hook may be applied to trees
which are not target-specific extended scalar types; it should return
@code{NULL} for all arguments it does not recognize. If the return
value is not @code{NULL}, it is assumed to be a string constant, not a
string allocated with malloc.

Target-specific scalar types might be new fundamental types or
qualified versions of ordinary fundamental types.  Encode new
fundamental types as @samp{@w{u @var{n} @var{name}}}, where @var{name}
is the name used for the type in source code, and @var{n} is the
length of @var{name} in decimal.  Encode qualified versions of
ordinary types as @samp{@w{U @var{n} @var{name} @var{code}}}, where
@var{name} is the name used for the type qualifier in source code,
@var{n} is the length of @var{name} as above, and @var{code} is the
code used to represent the unqualified version of this type.  (See
@code{write_builtin_type} in @file{cp/mangle.c} for the list of
codes.)  In both cases the spaces are for clarity; do not include any
spaces in your string.

The default version of this hook always returns @code{NULL}, which is
appropriate for a target that does not define any extended scalar
@end deftypefn

I have mixed feelings here. While I agree that it's good to point out that these extended scalar types must follow the C++ ABI mangling rules for vendor extensions, I don't quite see why it is necessary to narrowly define these types as 'new fundamental types' or 'qualified versions of ordinary fundamental types'. Actually, I'm not even certain that the AltiVec extended scalar types meet either of these definitions. :-( For example, is 'bool int' really a qualified version of an ordinary fundamental type? Moreover, these four AltiVec "types" cannot be used on their own, but only as vector elements.

Anyhoo, I'll incorporate your prose (most of which I agree with) into
the next version of my patch, and we can iterate from there.

(Come to think of it, we should do something about the _pretty-printing_
of these types.  Currently, error messages refer to nonsensical things
like '__bool int __vector__' and '__bool short __vector__'.  I'll whip
up a separate patch.)



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