Richard Earnshaw wrote: > You confused me for a bit with the reference to "line numbers", but I > think you must mean "lane numbers".
Indeed, sorry for the confusion. > FTR, I see no reason why GCC would have problems with 64-bit vectors in > big-endian mode, it's only 128-bit (and larger) vectors that pose a > problem (ok, the HW numbers the lanes from the other end, but the > transformation is trivial). The transformation may be trivial, but it is not done (by the original code) :-) The problem is that, as I understand, "subpart" numbers used as argument to "vec_select" are supposed to use the numbering that array indexes in an in-memory array would have; this is different from the NEON lane numbers in big-endian mode. The existing neon_vst1_lane<mode> pattern, however, directly uses a NEON lane number as "subpart" number. This usually does not cause visible problems, since it does the same both when expanding the pattern and when recognizing the pattern. However, in theory, common middle-end code might also look at the subpart numbers (e.g. during simplification), and it will assume the standard ordering is used ... All other code in neon.md *either* transforms the NEON lane numbers into RTL subpart numbers and put those in vec_select etc. *or* uses a NEON lane number unchanged as argument of an UNSPEC. It was only this one pattern that broke this rule. > This is OK. Checked in. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
