Re: [03/nn] Allow vector CONSTs

[Jeff Law <law at redhat dot com>]

On 10/23/2017 05:18 AM, Richard Sandiford wrote:
> This patch allows (const ...) wrappers to be used for rtx vector
> constants, as an alternative to const_vector.  This is useful
> for SVE, where the number of elements isn't known until runtime.
Right.  It's constant, but not knowable at compile time.  That seems an
exact match for how we've used CONST.

> 
> It could also be useful in future for fixed-length vectors, to
> reduce the amount of memory needed to represent simple constants
> with high element counts.  However, one nice thing about keeping
> it restricted to variable-length vectors is that there is never
> any need to handle combinations of (const ...) and CONST_VECTOR.
Yea, but is the memory consumption of these large vectors a real
problem?  I suspect, relative to other memory issues they're in the noise.

> 
> 
> 2017-10-23  Richard Sandiford  <richard.sandiford@linaro.org>
> 	    Alan Hayward  <alan.hayward@arm.com>
> 	    David Sherwood  <david.sherwood@arm.com>
> 
> gcc/
> 	* doc/rtl.texi (const): Update description of address constants.
> 	Say that vector constants are allowed too.
> 	* common.md (E, F): Use CONSTANT_P instead of checking for
> 	CONST_VECTOR.
> 	* emit-rtl.c (gen_lowpart_common): Use const_vec_p instead of
> 	checking for CONST_VECTOR.
> 	* expmed.c (make_tree): Use build_vector_from_val for a CONST
> 	VEC_DUPLICATE.
> 	* expr.c (expand_expr_real_2): Check for vector modes instead
> 	of checking for CONST_VECTOR.
> 	* rtl.h (const_vec_p): New function.
> 	(const_vec_duplicate_p): Check for a CONST VEC_DUPLICATE.
> 	(unwrap_const_vec_duplicate): Handle them here too.
My only worry here is code that is a bit loose in checking for a CONST,
but not the innards and perhaps isn't prepared for for the new forms
that appear inside the CONST.

If we have such problems I'd expect it's in the targets as the targets
have traditionally have had to validate the innards of a CONST to ensure
it could be handled by the assembler/linker.  Hmm, that may save the
targets since they'd likely need an update to LEGITIMATE_CONSTANT_P to
ever see these new forms.

Presumably an aarch64 specific patch to recognize these as valid
constants in LEGITIMATE_CONSTANT_P is in the works?

OK for the trunk.

jeff