On Mon, 2013-08-12 at 11:54 +0100, Tejas Belagod wrote: > >> 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?
No. The least significant bits of any register are the rightmost bits, and big-endian numbering begins at the left. (I don't really like the commentary, since "least significant bits" isn't a very good term to use with vectors.) Analogously, a 64-bit integer is numbered with 0 on the left being the most significant bit, and 63 on the right being the least significant bit. Thanks, Bill > > 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. > >> > > > > > >
