[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR

["rth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.