http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51074
--- Comment #8 from Richard Henderson <rth at gcc dot gnu.org> 2011-11-22
16:08:17 UTC ---
No, Jakub, vector elements are in memory order. There is no adjustment
to be made here.
Unfortunately ppc represents its interleave patterns non-standard, but
one can interpret. E.g. the ultimate implementation of
vec_interleave_low_v4si:
(define_insn "altivec_vmrglw"
[(set (match_operand:V4SI 0 "register_operand" "=v")
(vec_merge:V4SI
(vec_select:V4SI (match_operand:V4SI 1 "register_operand" "v")
(parallel [(const_int 2)
(const_int 0)
(const_int 3)
(const_int 1)]))
(vec_select:V4SI (match_operand:V4SI 2 "register_operand" "v")
(parallel [(const_int 0)
(const_int 2)
(const_int 1)
(const_int 3)]))
(const_int 5)))]
By my reading that's { 4+0, 0, 4+1, 1 } if you consider op2 to be +4.
Which is ... argument reversed from the normal { 0, 4, 1, 5 } that we
expected, but certainly not the { 2, 6, 3, 7 } that you were going to
generate with that patch.
As for the swapped operands... that does seem to correlate with the
actual output quoted in comment #6. It seems like we need to dig and
figure out if the rtl is wrong, or if arguments got swapped along the
N stage path between vector.md and the ultimate altivec.md pattern.
