https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232
--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Sam James from comment #0)
> (insn 160 159 161 26 (parallel [
> (set (reg:V2QI 250 [ vect_patt_207.470_183 ])
> (minus:V2QI (reg:V2QI 251)
> (reg:V2QI 249 [ vect__4.468_451 ])))
> (clobber (reg:CC 17 flags))
> ])
This is the definition of the offending pattern in mmx.md:
(define_insn "<insn>v2qi3"
[(set (match_operand:V2QI 0 "register_operand" "=?Q,x,Yw")
(plusminus:V2QI
(match_operand:V2QI 1 "register_operand" "<comm>0,0,Yw")
(match_operand:V2QI 2 "register_operand" "Q,x,Yw")))
(clobber (reg:CC FLAGS_REG))]
"!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
"#"
[(set_attr "isa" "*,sse2_noavx,avx")
(set_attr "type" "multi,sseadd,sseadd")
(set_attr "mode" "QI,TI,TI")])
where -march=i686 (aka pentiumpro) implies TARGET_PARTIAL_REG_STALL, so it
should be disabled unless optimizing for size. I wonder if
optimize_function_for_size_p is stable during the LTO compilation, but we have
plenty of usages like the above throughout x86 .md files and there were no
problems reported.
Another possibility is that the instruction RTX is emitted without checking of
the pattern condition, the testcase is compiled with -O3, so
optimize_function_for_size_p should also be false.
I don't see anything wrong with the above pattern. The failure also happens
very early into the RTL part of the compilation (vregs pass is the first pass
that tries to recognize the pattern), so my bet is on middle-end emitting insn
pattern without checking for pattern availability.
