Re: [RFC] vector subscripts/BIT_FIELD_REF in Big Endian.

[Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>]

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.
>