Re: [03/nn] Allow vector CONSTs

[Richard Sandiford <richard.sandiford@linaro.org>]

Jeff Law <law@redhat.com> writes:
> 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.

Yeah, maybe not, especially since the elements themselves are shared.

>> 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?

Yeah, via the const_vec_duplicate_p helper.  For the default
variable-length mode of SVE we use the (const ...) while for the
fixed-length mode we use (const_vector ...) as normal.  Advanced SIMD
always uses (const_vector ...).

> OK for the trunk.
>
> jeff

Thanks,
Richard