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.
...
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.
Thanks for your reply.
Sorry, I'm still a bit confused here. The reduc_splus_ documentation says
"Compute the sum of the signed elements of a vector. The vector is operand 1,
and the scalar result is stored in the least significant bits of operand 0
(also a vector)."
Shouldn't this mean the scalar result should be in bitpos 0 which is the left
end of the register in BIG ENDIAN?
Thanks,
Tejas
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.
