Jeff Law <l...@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.sandif...@linaro.org> >> Alan Hayward <alan.hayw...@arm.com> >> David Sherwood <david.sherw...@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
