This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: New hook for custom-mangling of C++ scalars
On 20 Mar 2004, at 18.31, Zack Weinberg wrote:
Ziemowit Laski <zlaski@apple.com> 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
^the
Ok.
+ /* 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 =
(*targetm.mangle_scalar_type)(type)))
+ {
+ 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);
return;
}
}
/* otherwise... */
Indeed, your approach is a lot cleaner.
+@deftypefn {Target Hook} const char * TARGET_MANGLE_SCALAR_TYPE (tree
@var{type})
+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
that
+the default C++ mangling scheme should be used. The default target
hook
+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
types.
@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.)
Thanks,
--Zem