On Sun, Jan 12, 2014 at 7:53 PM, Bill Schmidt
<wschm...@linux.vnet.ibm.com> wrote:
> This patch provides for interpreting element numbers for the Altivec
> vec_insert and vec_extract intrinsics as big-endian (left to right in a
> vector register) when targeting a little endian machine and specifying
> -maltivec=be. New test cases are added to test this functionality on
> all supported vector types.
>
> Bootstrapped and tested with no new regressions on
> powerpc64{,le}-unknown-linux-gnu. Ok for trunk?
>
> Thanks,
> Bill
>
>
> gcc:
>
> 2014-01-12 Bill Schmidt <wschm...@linux.vnet.ibm.com>
>
> * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> Implement -maltivec=be for vec_insert and vec_extract.
>
> gcc/testsuite:
>
> 2014-01-12 Bill Schmidt <wschm...@linux.vnet.ibm.com>
>
> * gcc.dg/vmx/insert.c: New.
> * gcc.dg/vmx/insert-be-order.c: New.
> * gcc.dg/vmx/extract.c: New.
> * gcc.dg/vmx/extract-be-order.c: New.
> + if (!BYTES_BIG_ENDIAN && rs6000_altivec_element_order == 2)
> + {
> + int last_elem = TYPE_VECTOR_SUBPARTS (arg1_type) - 1;
> + double_int di_last_elem = double_int::from_uhwi (last_elem);
> + arg2 = fold_build2_loc (loc, MINUS_EXPR, TREE_TYPE (arg2),
> + double_int_to_tree (TREE_TYPE (arg2),
> + di_last_elem),
> + arg2);
> + }
Please change last_elem to unsigned int in both blocks of code. And I
believe that GCC provides a more direct API to create a Tree from
last_elem than the double_int::from_uhwi() and double_int_to_tree()
dance because it seems that the value is constant for each instance.
build_int_cstu()?
Okay with those changes.
Thanks, David
