On 1/12/2026 9:49 PM, Andrew Pinski wrote:
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:
About to call it a night. I'll try to spin this suggestion up tomorrow
(I'm in meetings all day, but hopefully I can find a few minutes of
downtime to cobble this together quickly).
Thanks,
jeff
