On 7/12/19 1:44 AM, Richard Sandiford wrote: > Richard Sandiford <richard.sandif...@arm.com> writes: >> This patch rewrites the way simplify_subreg handles constants. >> It uses similar native_encode/native_decode routines to the >> tree-level handling of VIEW_CONVERT_EXPR, meaning that we can >> move between rtx constants and the target memory image of them. >> >> The main point of this patch is to support subregs of constant-length >> vectors for VLA vectors, beyond the very simple cases that were already >> handled. Many of the new tests failed before the patch for variable- >> length vectors. >> >> The boolean side is tested more by the upcoming SVE ACLE work. >> >> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. >> OK to install? > I made a last-minute change after testing, to use uintNN_t types > for target_unit rather than the original unsigned char/short/int. > Of course, that doesn't survive a libgcc build since <stdint.h> > isn't included there. > > Fixed below, and posted as tested this time. > > Richard > > > 2019-07-12 Richard Sandiford <richard.sandif...@arm.com> > > gcc/ > * defaults.h (TARGET_UNIT): New macro. > (target_unit): New type. > * rtl.h (native_encode_rtx, native_decode_rtx) > (native_decode_vector_rtx, subreg_size_lsb): Declare. > (subreg_lsb_1): Turn into an inline wrapper around subreg_size_lsb. > * rtlanal.c (subreg_lsb_1): Delete. > (subreg_size_lsb): New function. > * simplify-rtx.c: Include rtx-vector-builder.h > (simplify_immed_subreg): Delete. > (native_encode_rtx, native_decode_vector_rtx, native_decode_rtx) > (simplify_const_vector_byte_offset, simplify_const_vector_subreg): New > functions. > (simplify_subreg): Use them. > (test_vector_subregs_modes, test_vector_subregs_repeating) > (test_vector_subregs_fore_back, test_vector_subregs_stepped) > (test_vector_subregs): New functions. > (test_vector_ops): Call test_vector_subregs for integer vector > modes with at least 2 elements. This just turns out to be amazingly painful to work through and I don't particularly see any good breakdown which would make it obvious where the behavioral changes are vs just refactoring.
Given your long history with GCC and your expertise in RTL as well as the SVE space I'm inclined to say go for it and we'll cope with any fallout. Jeff
