On 8/25/18 1:09 PM, Segher Boessenkool wrote: > Hey, > > On Sat, Aug 25, 2018 at 12:15:16PM -0500, Bill Schmidt wrote: >> On 8/20/18 4:44 PM, Will Schmidt wrote: >>> Enable GIMPLE folding of the vec_splat() intrinsic. (v3). >>> >>> This uses the tree_vec_extract() function out of tree-vect-generic.c >>> to retrieve the splat value, which is a BIT_FIELD_REF. That function is >>> made non-static as part of this change. >>> >>> Testcases are already in-tree. >>> >>> V2 updates, per feedback previously received. >>> Forced arg1 into range (modulo #elements) before attempting to extract >>> the splat value. >>> Removed the (now unnecessary) code that did bounds-checking before calling >>> the tree_vec_extract helper. >>> Used arg0_type rather than lhs_type for calculating the tree size. >>> >>> V3 updates, inspired by additional offline discussion with Segher. >>> Noting that for vec_splat(arg1,arg2), the ABI describes ARG2 as an element >>> number less than the number of elements supported by the respective ARG1 >>> type, so we do not attempt to gimple-fold the intrinsic if we determine our >>> value is out of range. Thus, the initial check ensures that ARG1 is both >>> constant and has a valid index into ARG0. >>> The subsequent modulo operation is no longer necessary, and has been >>> removed. >>> 2018-08-20 Will Schmidt <will_schm...@vnet.ibm.com> >>> >>> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add >>> support for >>> early gimple folding of vec_splat(). > s/ // > >>> * tree-vect-generic.c: Remove static from tree_vec_extract() >>> definition. >>> * gimple-fold.h: Add an extern define for tree_vec_extract(). > s/ / / > >>> + /* Only fold the vec_splat_*() if arg1 is both a constant value, and a >>> valid >>> + index into the arg0 vector. */ > Needs two more spaces indent? > >>> + unsigned int n_elts = VECTOR_CST_NELTS (arg0); >>> + if (TREE_CODE (arg1) != INTEGER_CST >>> + || TREE_INT_CST_LOW (arg1) > (n_elts -1)) >> Space between - and 1. >> >> I'm still not convinced we should do this. The semantics of vec_splat are >> to select the element as arg1 modulo n_elts. Odd as it seems, it's >> historically >> valid for values between 0 and 31 to be used regardless of the value of >> n_elts. > But, the assembler complains. So it never worked, and it seems better to > not allow it in the compiler either. > > A lot of existing testcases generate assembler code the assembler chokes > on -- but the testcases are dg-do compile, so the assembler isn't run. > > This is also PR86987; I have patches, but it snowballs because of the > aforementioned existing wrong testcases. > >> Since arg1 is a constant we can easily bring it into valid range and expand >> it >> early, rather than losing optimization opportunities by keeping this as a >> built-in call. > We should just error on invalid input. > >> Do we have test cases for arg1 in {n_elts, ..., 31}? What's GCC's current >> behavior? Maybe we already aren't honoring this technically legal case? > We do, lots. Sometimes we compile it; the assembler chokes on the output > (but the assembler is not run in those testcases). Sometimes we ICE.
Thanks for the reminders. :-) No concerns, then. Bill > >> Otherwise looks fine to me, though of course I can't approve. > Looks fine to me, too. > >>> + int splat_elem_size = TREE_INT_CST_LOW (size_in_bytes (arg0_type)) >>> + * BITS_PER_UNIT / n_elts; > (Well one thing then... Wrong indent?) > > > Segher >