On Mon, Jan 12, 2026 at 7:56 PM Jeffrey Law <[email protected]> wrote: > > > > On 1/12/2026 2:58 PM, Andrew Pinski wrote: > > I think this should be closer to what I did for VEC_SHL_INSERT in > r16-4742-gfcde4c81644aec (this was based on the review where I tried > to do a similar thing as you did: > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658275.html ). > > That is, in fold_const_call (in fold-const.cc) add VEC_EXTRACT case > and do similar as fold_const_vec_shl_insert. > Something like: > ``` > static tree > fold_const_vec_extract (tree, tree arg0, tree arg1) > { > if (TREE_CODE (arg0) != VECTOR_CST) > return NULL_TREE; > > /* vec_extract ( dup(CST), N) -> CST. */ > if (tree elem = uniform_vector_p (arg0)) > return elem; > > return NULL_TREE; > } > ``` > And also in match.pd add: > ``` > (simplify > (IFN_VEC_EXTRACT (vec_duplicate @0) @1) > @0) > ``` > > I don't think we need to care about the bounds check on @1 either > because then it would be undefined anyways. > > Uniform vectors can come in different forms. They can be a VEC_DUPLICATE, > VECTOR_CST or even a CONSTRUCTOR node. uniform_vector_p knows how to handle > all three cases already. So while that solution is simpler, I suspect it's > leaving good opportunities on the floor and may not even cover the regression > in question (I haven't checked that).
Note your current pattern only handles VECTOR_CST because that is only valid as an operand for the function call. For a CONSTRUCTOR or a VEC_DUPLICATE, @0 will be a SSA_NAME as CONSTRUCTOR/VEC_DUPLICATEs are only valid if alone in a stmt and uniform_vector_p will return false for a SSA_NAME. You could change the patch to be similar to what I originally did for IFN_VEC_SHL_INSERT (https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658274.html); though Richard had the same suggestion as I have above: > For the case in question implementing fold_const_call would be better. Thanks, Andrew Pinski > > > > > Jeff
