Ping: [C++ PATCH] Opt out of GNU vector extensions for built-in SVE types
Richard Sandiford
richard.sandiford@arm.com
Tue Dec 3 12:40:00 GMT 2019
Jason Merrill <jason@redhat.com> writes:
> On 11/29/19 5:59 AM, Richard Sandiford wrote:
>> Ping
>>
>> Richard Sandiford <richard.sandiford@arm.com> writes:
>>> This is the C++ equivalent of r277950, which prevented the
>>> use of the GNU vector extensions with SVE vector types for C.
>>> [https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=277950].
>>> I've copied the rationale below for reference.
>>>
>>> The changes here are very similar to the C ones. Perhaps the only
>>> noteworthy thing (that I know of) is that the patch continues to treat
>>> !gnu_vector_type_p vector types as literal types/potential constexprs.
>>> Disabling the GNU vector extensions shouldn't in itself stop the types
>>> from being literal types, since whatever the target provides instead
>>> might be constexpr material.
>>>
>>> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>>>
>>> Richard
>>>
>>> -------------------------------------------------------------------------
>>> The AArch64 port defines built-in SVE types at start-up under names
>>> like __SVInt8_t. These types are represented in the front end and
>>> gimple as normal VECTOR_TYPEs and are code-generated as normal vectors.
>>> However, we'd like to stop the frontends from treating them in the
>>> same way as GNU-style ("vector_size") vectors, for several reasons:
>>>
>>> (1) We allowed the GNU vector extensions to be mixed with Advanced SIMD
>>> vector types and it ended up causing a lot of confusion on big-endian
>>> targets. Although SVE handles big-endian vectors differently from
>>> Advanced SIMD, there are still potential surprises; see the block
>>> comment near the head of aarch64-sve.md for details.
>>>
>>> (2) One of the SVE vectors is a packed one-bit-per-element boolean vector.
>>> That isn't a combination the GNU vector extensions have supported
>>> before. E.g. it means that vectors can no longer decompose to
>>> arrays for indexing, and that not all elements are individually
>>> addressable. It also makes it less clear which order the initialiser
>>> should be in (lsb first, or bitfield ordering?). We could define
>>> all that of course, but it seems a bit weird to go to the effort
>>> for this case when, given all the other reasons, we don't want the
>>> extensions anyway.
>>>
>>> (3) The GNU vector extensions only provide full-vector operations,
>>> which is a very artifical limitation on a predicated architecture
>>> like SVE.
>>>
>>> (4) The set of operations provided by the GNU vector extensions is
>>> relatively small, whereas the SVE intrinsics provide many more.
>>>
>>> (5) It makes it easier to ensure that (with default options) code is
>>> portable between compilers without the GNU vector extensions having
>>> to become an official part of the SVE intrinsics spec.
>>>
>>> (6) The length of the SVE types is usually not fixed at compile time,
>>> whereas the GNU vector extension is geared around fixed-length
>>> vectors.
>>>
>>> It's possible to specify the length of an SVE vector using the
>>> command-line option -msve-vector-bits=N, but in principle it should
>>> be possible to have functions compiled for different N in the same
>>> translation unit. This isn't supported yet but would be very useful
>>> for implementing ifuncs. Once mixing lengths in a translation unit
>>> is supported, the SVE types should represent the same type throughout
>>> the translation unit, just as GNU vector types do.
>>>
>>> However, when -msve-vector-bits=N is in effect, we do allow conversions
>>> between explicit GNU vector types of N bits and the corresponding SVE
>>> types. This doesn't undermine the intent of (5) because in this case
>>> the use of GNU vector types is explicit and intentional. It also doesn't
>>> undermine the intent of (6) because converting between the types is just
>>> a conditionally-supported operation. In other words, the types still
>>> represent the same types throughout the translation unit, it's just that
>>> conversions between them are valid in cases where a certain precondition
>>> is known to hold. It's similar to the way that the SVE vector types are
>>> defined throughout the translation unit but can only be used in functions
>>> for which SVE is enabled.
>>> -------------------------------------------------------------------------
>>
>> 2019-11-08 Richard Sandiford <richard.sandiford@arm.com>
>>
>> gcc/cp/
>> * cp-tree.h (CP_AGGREGATE_TYPE_P): Check for gnu_vector_type_p
>> instead of VECTOR_TYPE.
>> * call.c (build_conditional_expr_1): Restrict vector handling
>> to vectors that satisfy gnu_vector_type_p. Don't treat the
>> "then" and "else" types as equivalent if they have the same
>> vector shape but differ in whether they're GNU vectors.
>> * cvt.c (ocp_convert): Only allow vectors to be converted
>> to bool if they satisfy gnu_vector_type_p.
>> (build_expr_type_conversion): Only allow conversions from
>> vectors if they satisfy gnu_vector_type_p.
>> * typeck.c (cp_build_binary_op): Only allow binary operators to be
>> applied to vectors if they satisfy gnu_vector_type_p.
>> (cp_build_unary_op): Likewise unary operators.
>> (build_reinterpret_cast_1):
>>
>> Index: gcc/cp/call.c
>> ===================================================================
>> --- gcc/cp/call.c 2019-11-08 08:31:19.000000000 +0000
>> +++ gcc/cp/call.c 2019-11-08 17:43:07.172264122 +0000
>> @@ -5397,6 +5401,7 @@ build_conditional_expr_1 (const op_locat
>> value category. */
>> if (((lvalue_p (arg2) && lvalue_p (arg3))
>> || (xvalue_p (arg2) && xvalue_p (arg3)))
>> + && gnu_vector_type_p (arg2_type) == gnu_vector_type_p (arg3_type)
>> && same_type_p (arg2_type, arg3_type))
>
> If the GNU-vector-ness differs, surely same_type_p should be false?
>
>> {
>> result_type = arg2_type;
>> @@ -5500,7 +5505,8 @@ build_conditional_expr_1 (const op_locat
>>
>> --The second and third operands have the same type; the result is of
>> that type. */
>> - if (same_type_p (arg2_type, arg3_type))
>> + if (gnu_vector_type_p (arg2_type) == gnu_vector_type_p (arg3_type)
>> + && same_type_p (arg2_type, arg3_type))
>
> Here too.
Although the types aren't supposed to support GNU-style vector operations
directly, they're still supposed to be structurally equivalent to GNU
vectors with the same size and element type. E.g.:
typedef uint8_t gnu_uint8_t __attribute__ ((vector_size (32)));
is structurally equivalent to svuint8_t for -msve-vector-bits=256.
svuint8_t and gnu_uint8_t (need to) have separate identities though,
since svuint8_t has an ABI-defined mangling that doesn't depend on
-msve-vector-bits, whereas GNU vector types have their established
target-independent mangling. So the SVE types are built like this:
vectype = build_distinct_type_copy (vectype);
gcc_assert (vectype == TYPE_MAIN_VARIANT (vectype));
SET_TYPE_STRUCTURAL_EQUALITY (vectype);
TYPE_ARTIFICIAL (vectype) = 1;
TYPE_INDIVISIBLE_P (vectype) = 1;
same_type_p seems to be operating at the structural level and doesn't
care whether the types are different enough to need different mangling.
I assumed it also shouldn't care whether the types had the same
restrictions on the operators they support.
If we do make same_type_p return false, we'd need checks elsewhere
to keep the test working. E.g.:
gnu_uint8_t init_gnu_u3 = { sve_u1 };
gnu_uint8_t init_gnu_u4 = { gnu_u1 };
needs reference_related_p to be true and requires:
/* If the constructor already has the array type, it's been through
digest_init, so we shouldn't try to do anything more. */
bool digested = same_type_p (atype, TREE_TYPE (init));
(build_vec_init) to be true. ISTR there are similar digest_init checks
elsewhere. The pointer checks:
svuint8_t *sve_ptr1 = &sve_u1;
svuint8_t *sve_ptr2 = &gnu_u1;
need comp_ptr_ttypes_real to be true. I can try doing it that way
instead if that seems better.
The reason for calling out gnu_vector_type_p above is that it isn't
clear whether x ? y : z should return typeof(y) or typeof(z) if y
and z are structurally equivalent but distinct.
I guess that's a problem even before the patch though. E.g.,
leaving SVE to one side, the AArch64 code:
#include <arm_neon.h>
typedef uint8_t gnu_uint8_t __attribute__ ((vector_size (16)));
void f(gnu_uint8_t x) {}
void g(uint8x16_t y) {}
correctly mangles f as _Z1fDv16_h and g as _Z1g12__Uint8x16_t. But:
void h1(decltype(*(int *)nullptr ? *(gnu_uint8_t *)nullptr : *(uint8x16_t *)nullptr)) {}
void h2(decltype(*(int *)nullptr ? *(uint8x16_t *)nullptr : *(gnu_uint8_t *)nullptr)) {}
mangles h1 as _Z2h1RDv16_h and h2 as _Z2h2R12__Uint8x16_t. If that's
the expected behaviour, maybe we should just embrace it for SVE too.
But if it isn't, is there some other check we should be using here
instead?
Thanks,
Richard
More information about the Gcc-patches
mailing list