f486280c53
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.
The patch adds a new flag to tree_type_common to select this behaviour.
(We currently have 17 bits free.) To avoid making the flag too specific
to vectors, I called it TYPE_INDIVISIBLE_P, to mean that the frontend
should not allow the components of the type to be accessed directly.
This could perhaps be useful in future for hiding the fact that a
type is an array, or for hiding the fields of a record or union.
The actual frontend changes are very simple, mostly just replacing
VECTOR_TYPE_P with gnu_vector_type_p in selected places.
One interesting case is:
/* Need to convert condition operand into a vector mask. */
if (VECTOR_TYPE_P (TREE_TYPE (ifexp)))
{
tree vectype = TREE_TYPE (ifexp);
tree elem_type = TREE_TYPE (vectype);
tree zero = build_int_cst (elem_type, 0);
tree zero_vec = build_vector_from_val (vectype, zero);
tree cmp_type = build_same_sized_truth_vector_type (vectype);
ifexp = build2 (NE_EXPR, cmp_type, ifexp, zero_vec);
}
in build_conditional_expr. This appears to be trying to support
elementwise conditions like "vec1 ? vec2 : vec3", which is something
the C++ frontend supports. However, this code can never trigger AFAICT,
because "vec1" does not survive c_objc_common_truthvalue_conversion:
case VECTOR_TYPE:
error_at (location, "used vector type where scalar is required");
return error_mark_node;
Even if it did, the operation should be a VEC_COND_EXPR rather
than a COND_EXPR.
I've therefore left that condition as-is, but added tests for the
"vec1 ? vec2 : vec3" case to make sure that we don't accidentally
allow it for SVE vectors in future.
2019-11-08 Richard Sandiford <richard.sandiford@arm.com>
gcc/
* tree-core.h (tree_type_common::indivisible_p): New member variable.
* tree.h (TYPE_INDIVISIBLE_P): New macro.
* config/aarch64/aarch64-sve-builtins.cc (register_builtin_types):
Treat the vector types as indivisible.
gcc/c-family/
* c-common.h (gnu_vector_type_p): New function.
* c-common.c (c_build_vec_perm_expr): Require __builtin_shuffle
vectors to satisfy gnu_vector_type_p.
(c_build_vec_convert): Likewise __builtin_convertvector.
(convert_vector_to_array_for_subscript): Likewise when applying
implicit vector to array conversion.
(scalar_to_vector): Likewise when converting vector-scalar
operations to vector-vector operations.
gcc/c/
* c-convert.c (convert): Only handle vector conversions if one of
the types satisfies gnu_vector_type_p or if -flax-vector-conversions
allows it.
* c-typeck.c (build_array_ref): Only allow vector indexing if the
vectors satisfy gnu_vector_type_p.
(build_unary_op): Only allow unary operators to be applied to
vectors if they satisfy gnu_vector_type_p.
(digest_init): Only allow by-element initialization of vectors
if they satisfy gnu_vector_type_p.
(really_start_incremental_init): Likewise.
(push_init_level): Likewise.
(pop_init_level): Likewise.
(process_init_element): Likewise.
(build_binary_op): Only allow binary operators to be applied to
vectors if they satisfy gnu_vector_type_p.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c: New test.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c: Likewise.
From-SVN: r277950
|
||
|---|---|---|
| config | ||
| contrib | ||
| fixincludes | ||
| gcc | ||
| gnattools | ||
| gotools | ||
| include | ||
| INSTALL | ||
| intl | ||
| libada | ||
| libatomic | ||
| libbacktrace | ||
| libcc1 | ||
| libcpp | ||
| libdecnumber | ||
| libffi | ||
| libgcc | ||
| libgfortran | ||
| libgo | ||
| libgomp | ||
| libhsail-rt | ||
| libiberty | ||
| libitm | ||
| libobjc | ||
| liboffloadmic | ||
| libphobos | ||
| libquadmath | ||
| libsanitizer | ||
| libssp | ||
| libstdc++-v3 | ||
| libvtv | ||
| lto-plugin | ||
| maintainer-scripts | ||
| zlib | ||
| .dir-locals.el | ||
| .gitattributes | ||
| .gitignore | ||
| ABOUT-NLS | ||
| ar-lib | ||
| ChangeLog | ||
| ChangeLog.jit | ||
| ChangeLog.tree-ssa | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LIB | ||
| COPYING.RUNTIME | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| depcomp | ||
| install-sh | ||
| libtool-ldflags | ||
| libtool.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| lt~obsolete.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
This directory contains the GNU Compiler Collection (GCC). The GNU Compiler Collection is free software. See the files whose names start with COPYING for copying permission. The manuals, and some of the runtime libraries, are under different terms; see the individual source files for details. The directory INSTALL contains copies of the installation information as HTML and plain text. The source of this information is gcc/doc/install.texi. The installation information includes details of what is included in the GCC sources and what files GCC installs. See the file gcc/doc/gcc.texi (together with other files that it includes) for usage and porting information. An online readable version of the manual is in the files gcc/doc/gcc.info*. See http://gcc.gnu.org/bugs/ for how to report bugs usefully. Copyright years on GCC source files may be listed using range notation, e.g., 1987-2012, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually.