https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789
Peter Bergner <bergner at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bergner at gcc dot gnu.org --- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> --- Segher, I can have a look at this if you aren't already. I can see how of the builtin only uses the altivec_lxv_<mode>_2op patterm, how it would fail on a -m32 compile, since that pattern is disabled and you're supposed to use altivec_lxv_<mode>_2op_si. That said, why do we have two patterns at all? It seems like they should be able to be combined fairly easily using the P iterator: ; The next two patterns embody what lvx should usually look like. (define_insn "altivec_lvx_<mode>_2op" [(set (match_operand:VM2 0 "register_operand" "=v") (mem:VM2 (and:DI (plus:DI (match_operand:DI 1 "register_operand" "b") (match_operand:DI 2 "register_operand" "r")) (const_int -16))))] "TARGET_ALTIVEC && TARGET_64BIT" "lvx %0,%1,%2" [(set_attr "type" "vecload")]) ; 32-bit versions of the above. (define_insn "altivec_lvx_<mode>_2op_si" [(set (match_operand:VM2 0 "register_operand" "=v") (mem:VM2 (and:SI (plus:SI (match_operand:SI 1 "register_operand" "b") (match_operand:SI 2 "register_operand" "r")) (const_int -16))))] "TARGET_ALTIVEC && TARGET_32BIT" "lvx %0,%1,%2" [(set_attr "type" "vecload")])