Hi Kelvin,
On Wed, Mar 13, 2019 at 04:43:35PM -0500, Kelvin Nilsen wrote:
[ snip ]
This looks great, thanks! Okay for trunk. A few more comments, do
with it as you like:
> (altivec_expand_vec_ext_builtin): Use modular arithmetic to
> computer index.
s/computer/compute/
> @@ -14723,9 +14742,17 @@ altivec_expand_vec_ext_builtin (tree exp, rtx targ
> op0 = expand_normal (arg0);
> op1 = expand_normal (arg1);
>
> - /* Call get_element_number to validate arg1 if it is a constant. */
> if (TREE_CODE (arg1) == INTEGER_CST)
> - (void) get_element_number (TREE_TYPE (arg0), arg1);
> + {
> + unsigned HOST_WIDE_INT elt;
> + unsigned HOST_WIDE_INT size = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
> + unsigned int truncated_selector;
> + if (!tree_fits_uhwi_p (arg1))
> + error ("selector expression is out of range");
> + elt = tree_to_uhwi (arg1);
> + truncated_selector = elt % size;
> + op1 = GEN_INT (truncated_selector);
> + }
This error really should never happen, but maybe there is a better way to
report it (error_at maybe), or we can avoid it completely? It shouldn't
be too hard to extract the low few bits from any precision number.
Have you tested this? Is the error reasonable? Can you provoke it at all,
even with negative indices?
> +/* { dg-do run { target { int128 } } } */
You can write this simpler as
/* { dg-do run { target int128 } } */
Segher
