In this testcase we use an unmasked SVE loop with an Advanced SIMD
epilogue (because we don't yet support fully-masked downward loops).
The main loop uses a gather load for the strided access while the
epilogue loop builds the access from scalars instead. In both cases
we gimplify expressions based on the DR_STEP and insert them in the
loop preheader.
The problem was that the gather load code didn't copy the DR_STEP before
gimplifying it, meaning that the epilogue loop tried to reuse a result
from the (non-dominating) main loop preheader.
It looks at first glance like there could be other instances of this too,
but this patch just deals with the gather/scatter case.
2019-12-28 Richard Sandiford <email address hidden>
gcc/
* tree-vect-stmts.c (vect_get_strided_load_store_ops): Copy
DR_STEP before gimplifying it.
gcc/testsuite/
* gcc.dg/vect/vect-strided-epilogue-1.c: New test.
Check for a supported comparison when using EXTRACT_LAST_REDUCTION
The EXTRACT_LAST_REDUCTION handling needs to generate a separate
comparison instruction that feeds the vector mask argument of the
IFN_EXTRACT_LAST call. We weren't checking whether that comparison
was supported, leading to an ICE on the testcase.
2019-12-28 Richard Sandiford <email address hidden>
gcc/
* tree-vect-stmts.c (vectorizable_condition): For extract-last
reductions, check that the target supports the required comparison
operation.
gcc/testsuite/
* gcc.dg/vect/vect-cond-12.c: New test.
Add missing target check for fully-masked fold-left reductions
The fold-left reduction code has a (rarely-used) fallback that handles
cases in which the loop is fully-masked and the target has no native
support for the reduction. The fallback includea a VEC_COND_EXPR
between the reduction vector and a safe value, so we should check
whether that VEC_COND_EXPR is supported.
2019-12-27 Richard Sandiford <email address hidden>
gcc/
* tree-vect-loop.c (vectorizable_reduction): Check whether the
target supports the required VEC_COND_EXPR operation before
allowing the fallback handling of masked fold-left reductions.
gcc/testsuite/
* gcc.target/aarch64/sve/mixed_size_10.c: New test.
/* Ignore internal functions without direct optabs,
those are expanded specially and aggregate_value_p
on their result might result in undesirable warnings
with some backends. */
&& (!gimple_call_internal_p (stmt)
|| direct_internal_fn_p (gimple_call_internal_fn (stmt)))
&& aggregate_value_p (TREE_TYPE (gimple_call_lhs (stmt)), gimple_call_fndecl (stmt)))
But what the comment says applies to directly-mapped internal functions
too, since they're only used if the target supports them without a
libcall.
This was triggering an ICE on the attached testcase. The svld3 call
is folded to an IFN_LOAD_LANES, which returns an array of vectors with
VNx48QImode. Since no such return type can exist in C, the target hook
was complaining about an unexpected use of SVE modes. (And we want to
keep asserting for that, so that we don't accidentally define an ABI for
an unexpected corner case.)
2019-12-12 Richard Sandiford <email address hidden>
gcc/
* tree-nrv.c (pass_return_slot::execute): Handle all internal
functions the same way, rather than singling out those that
aren't mapped directly to optabs.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/nrv_1.c: New test.
One problem with adding an N-bit vector extension to an existing
architecture is to decide how N-bit vectors should be passed to
functions and returned from functions. Allowing all N-bit vector
types to be passed in registers breaks backwards compatibility,
since N-bit vectors could be used (and emulated) before the vector
extension was added. But always passing N-bit vectors on the
stack would be inefficient for things like vector libm functions.
For SVE we took the compromise position of predefining new SVE vector
types that are distinct from all existing vector types, including
GNU-style vectors. The new types are passed and returned in an
efficient way while existing vector types are passed and returned
in the traditional way. In the right circumstances, the two types
are inter-convertible.
The C frontend maintains this distinction, using VIEW_CONVERT_EXPR
to convert from one type to the other. However, the distinction can
be lost during gimple, which treats two vector types with the same
mode, number of elements, and element type as equivalent. And for
most targets that's the right thing to do.
This patch therefore adds a hook that lets the target choose
whether such vector types are indeed equivalent.
Note that the new tests fail for -mabi=ilp32 in the same way as other
ACLE-based tests. I'm still planning to fix that as a follow-on.
2019-12-12 Richard Sandiford <email address hidden>
gcc/
* target.def (compatible_vector_types_p): New target hook.
* hooks.h (hook_bool_const_tree_const_tree_true): Declare.
* hooks.c (hook_bool_const_tree_const_tree_true): New function.
* doc/tm.texi.in (TARGET_COMPATIBLE_VECTOR_TYPES_P): New hook.
* doc/tm.texi: Regenerate.
* gimple-expr.c: Include target.h.
(useless_type_conversion_p): Use targetm.compatible_vector_types_p.
* config/aarch64/aarch64.c (aarch64_compatible_vector_types_p): New
function.
(TARGET_COMPATIBLE_VECTOR_TYPES_P): Define.
* config/aarch64/aarch64-sve-builtins.cc (gimple_folder::convert_pred):
Use the original predicate if it already has a suitable type.
gcc/testsuite/
* gcc.target/aarch64/sve/pcs/gnu_vectors_1.c: New test.
* gcc.target/aarch64/sve/pcs/gnu_vectors_2.c: Likewise.
Normally we only create SVE ACLE functions when arm_sve.h is included.
But for LTO we need to do it at start-up, so that the functions are
already defined when streaming in the LTO objects.
One hitch with doing that is that LTO doesn't yet implement the
simulate_enum_decl langhook. This patch adds a simple default
implementation that it can use.
2019-12-19 Richard Sandiford <email address hidden>
gcc/
* langhooks-def.h (lhd_simulate_enum_decl): Declare.
(LANG_HOOKS_SIMULATE_ENUM_DECL): Use it.
* langhooks.c: Include stor-layout.h.
(lhd_simulate_enum_decl): New function.
* config/aarch64/aarch64-sve-builtins.cc (init_builtins): Call
handle_arm_sve_h for the LTO frontend.
(register_vector_type): Cope with null returns from pushdecl.
gcc/testsuite/
* gcc.target/aarch64/sve/pcs/asm_4.c: New test.
[AArch64] Use type attributes to mark types that use the SVE PCS
The SVE port needs to maintain a different type identity for
GNU vectors and "SVE vectors", since the types use different ABIs.
Until now we've done that using pointer equality between the
TYPE_MAIN_VARIANT and the built-in SVE type.
However, as Richard B noted, that doesn't work well for LTO,
where we stream both GNU and SVE types from a file instead of
creating them directly. We need a mechanism for distinguishing
the types using streamed type information.
This patch does that using a new type attribute. This attribute
is only meant to be used for the built-in SVE types and shouldn't
be user-visible. The patch tries to ensure this by including a space
in the attribute name, like we already do for things like "fn spec"
and "omp declare simd".
2019-12-19 Richard Sandiford <email address hidden>
gcc/
* config/aarch64/aarch64-protos.h (aarch64_sve::svbool_type_p)
(aarch64_sve::nvectors_if_data_type): Replace with...
(aarch64_sve::builtin_type_p): ...this.
* config/aarch64/aarch64-sve-builtins.cc: Include attribs.h.
(find_vector_type): Delete.
(add_sve_type_attribute): New function.
(lookup_sve_type_attribute): Likewise.
(register_builtin_types): Add an "SVE type" attribute to each type.
(register_tuple_type): Likewise.
(svbool_type_p, nvectors_if_data_type): Delete.
(mangle_builtin_type): Use lookup_sve_type_attribute.
(builtin_type_p): Likewise. Add an overload that returns the
number of constituent vector and predicate registers.
* config/aarch64/aarch64.c (aarch64_sve_argument_p): Delete.
(aarch64_returns_value_in_sve_regs_p): Use aarch64_sve::builtin_type_p
instead of aarch64_sve_argument_p.
(aarch64_takes_arguments_in_sve_regs_p): Likewise.
(aarch64_pass_by_reference): Likewise.
(aarch64_function_value_1): Likewise.
(aarch64_return_in_memory): Likewise.
(aarch64_layout_arg): Likewise.
Don't mangle attributes that have a space in their name
The SVE port needs to maintain a different type identity for
GNU vectors and "SVE vectors" even during LTO, since the types
use different ABIs. The easiest way of doing that seemed to be
to use type attributes. However, these type attributes shouldn't
be user-facing; they're just a convenient way of representing the
types internally in GCC.
There are already several internal-only attributes, such as "fn spec"
and "omp declare simd". They're distinguished from normal user-facing
attributes by having a space in their name, which means that it isn't
possible to write them directly in C or C++.
Taking the same approach mostly works well for SVE. The only snag
I've hit so far is that the new attribute needs to (and only exists to)
affect type identity. This means that it would normally get included
in mangled names, to distinguish it from types without the attribute.
However, the SVE ABI specifies a separate mangling for SVE vector types,
rather than using an attribute mangling + a normal vector mangling.
So we need some way of suppressing the attribute mangling for this case.
There are currently no other target-independent or target-specific
internal-only attributes that affect type identity, so this patch goes
for the simplest fix of skipping mangling for attributes whose names
contain a space. Other options I thought about were:
(1) Also make sure that targetm.mangled_type returns nonnull.
(2) Check directly for the target-specific name.
(3) Add a new target hook.
(4) Add new information to attribute_spec. This would be very invasive
at this stage, but maybe we should consider replacing all the boolean
fields with flags? That should make the tables slightly easier to
read and would make adding new flags much simpler in future.
2019-12-18 Richard Sandiford <email address hidden>
gcc/cp/
* mangle.c (write_CV_qualifiers_for_type): Don't mangle attributes
that contain a space.
IFN_DIV_POW2 currently requires all elements to be shifted by the
same amount, in a similar way as for WIDEN_LSHIFT_EXPR. This patch
enforces that when building the SLP tree.
If in future targets want to support IFN_DIV_POW2 without this
restriction, we'll probably need the kind of vector-vector/
vector-scalar split that we already have for normal shifts.
2019-12-19 Richard Sandiford <email address hidden>
gcc/
* tree-vect-slp.c (vect_build_slp_tree_1): Require all shifts
in an IFN_DIV_POW2 node to be equal.
