Andreas Krebbel wrote:
> +; vec_set is supposed to *modify* an existing vector so operand 0 is > +; duplicated as input operand. > +(define_expand "vec_set<mode>" > + [(set (match_operand:V 0 "register_operand" > "") > + (unspec:V [(match_operand:<non_vec> 1 "general_operand" > "") > + (match_operand:SI 2 "shift_count_or_setmem_operand" > "") This is probably only cosmetic, but should we use nonmemory_operand here instead of shift_count_or_setmem_operand (just like everywhere else now)? > +(define_expand "vec_extract<mode>" > + [(set (match_operand:<non_vec> 0 "nonimmediate_operand" "") > + (unspec:<non_vec> [(match_operand:V 1 "register_operand" "") > + (match_operand:SI 2 "shift_count_or_setmem_operand" > "")] Likewise. > +(define_insn "*vec_set<mode>_plus" > + [(set (match_operand:V 0 "register_operand" "=v") > + (unspec:V [(match_operand:<non_vec> 1 "general_operand" "d") > + (plus:SI (match_operand:SI 2 "register_operand" "a") > + (match_operand:SI 4 "const_int_operand" "n")) > + (match_operand:V 3 "register_operand" "0")] > + UNSPEC_VEC_SET))] > + "TARGET_VX" > + "vlvg<bhfgq>\t%v0,%1,%4(%2)" > + [(set_attr "op_type" "VRS")]) Wouldn't it be better to use %Y4 instead of %4 here? Or does the middle-end guarantee that this is never out of range? > +(define_insn "*vec_extract<mode>_plus" > + [(set (match_operand:<non_vec> 0 > "nonimmediate_operand" "=d,QR") > + (unspec:<non_vec> [(match_operand:V 1 "register_operand" > "v, v") > + (plus:SI (match_operand:SI 2 "nonmemory_operand" > "a, I") > + (match_operand:SI 3 "const_int_operand" > "n, I"))] > + UNSPEC_VEC_EXTRACT))] > + "TARGET_VX" > + "@ > + vlgv<bhfgq>\t%0,%v1,%3(%2) > + vste<bhfgq>\t%v1,%0,%2" > + [(set_attr "op_type" "VRS,VRX")]) Likewise for %3. Also, the second alternative seems odd, it matches solely a PLUS of two CONST_INTs, which is not canonical RTL ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
