On Mon, 2013-08-05 at 11:47 +0100, Tejas Belagod wrote:
> Hi,
>
> I'm looking for some help understanding how BIT_FIELD_REFs work with
> big-endian.
>
> Vector subscripts in this example:
>
> #define vector __attribute__((vector_size(sizeof(int)*4) ))
>
> typedef int vec vector;
>
> int foo(vec a)
> {
> return a[0];
> }
>
> gets lowered into array accesses by c-typeck.c
>
> ;; Function foo (null)
> {
> return *(int *) &a;
> }
>
> and gets gimplified into BIT_FIELD_REFs a bit later.
>
> foo (vec a)
> {
> int _2;
>
> <bb 2>:
> _2 = BIT_FIELD_REF <a_3(D), 32, 0>;
> return _2;
>
> }
>
> What's interesting to me here is the bitpos - does this not need
> BYTES_BIG_ENDIAN correction? This seems to be inconsistenct with what happens
> with reduction operations in the autovectorizer where the scalar result in
> the
> reduction epilogue gets extracted with a BIT_FIELD_REF but the bitpos there
> is
> corrected for BIG_ENDIAN.
a[0] is at the left end of the array in BIG_ENDIAN, and big-endian
machines number bits from the left, so bit position 0 is correct.
>
> ... from tree-vect-loop.c:vect_create_epilog_for_reduction ()
>
> /* 2.4 Extract the final scalar result. Create:
> s_out3 = extract_field <v_out2, bitpos> */
>
> if (extract_scalar_result)
> {
> tree rhs;
>
> if (dump_enabled_p ())
> dump_printf_loc (MSG_NOTE, vect_location,
> "extract scalar result");
>
> if (BYTES_BIG_ENDIAN)
> bitpos = size_binop (MULT_EXPR,
> bitsize_int (TYPE_VECTOR_SUBPARTS (vectype) -
> 1),
> TYPE_SIZE (scalar_type));
> else
> bitpos = bitsize_zero_node;
>
>
> For eg:
>
> int foo(int * a)
> {
> int i, sum = 0;
>
> for (i=0;i<16;i++)
> sum += a[i];
>
> return sum;
> }
>
> gets autovectorized into:
>
> ...
> vect_sum_9.17_74 = [reduc_plus_expr] vect_sum_9.15_73;
> stmp_sum_9.16_75 = BIT_FIELD_REF <vect_sum_9.17_74, 32, 96>;
> sum_76 = stmp_sum_9.16_75 + sum_47;
>
> the BIT_FIELD_REF here seems to have been corrected for BYTES_BIG_ENDIAN
Yes, because something else is going on here. This is a reduction
operation where the sum ends up in the rightmost element of a vector
register that contains four 32-bit integers. This is at position 96
from the left end of the register according to big-endian numbering.
>
> If vec_extract is defined in the back-end, how does one figure out if the
> BIT_FIELD_REF is a product of the gimplifier's indirect ref folding or the
> vectorizer's bit-field extraction and apply the appropriate correction in
> vec_extract's expansion? Or am I missing something that corrects
> BIT_FIELD_REFs
> between the gimplifier and the RTL expander?
There is no inconsistency here.
Hope this helps!
Bill
>
> Thanks,
> Tejas.
>
