On Mon, Nov 9, 2015 at 2:17 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> wrote: > On Mon, Nov 09, 2015 at 01:11:41PM -0800, David Edelsohn wrote: >> On Mon, Nov 9, 2015 at 11:57 AM, Segher Boessenkool >> <seg...@kernel.crashing.org> wrote: >> > On Mon, Nov 09, 2015 at 12:34:20PM -0500, Michael Meissner wrote: >> >> > > +(define_insn "*toc_fusionload_<mode>" >> >> > > + [(set (match_operand:QHSI 0 "int_reg_operand" "=&b,??r") >> >> > > + (match_operand:QHSI 1 "toc_fusion_mem_wrapped" "wG,wG")) >> >> > > + (unspec [(const_int 0)] UNSPEC_FUSION_ADDIS) >> >> > > + (use (match_operand:DI 2 "base_reg_operand" "r,r")) >> >> > > + (clobber (match_scratch:DI 3 "=X,&b"))] >> >> > > + "TARGET_TOC_FUSION_INT" >> >> > >> >> > Do you need that "??r" alternative? Same for the next define_insn. >> >> >> >> Yes unfortunately. The ??r catches the case where r0 is chosen. R0 is >> >> not a >> >> base register, and it can't be used for power8 gpr fusion (where you use >> >> the >> >> value being loaded for the ADDIS instruction), but it can be used for >> >> power9 >> >> fusion (where the ADDIS must be adjancent, but it no longer has to be the >> >> register being loaded). >> > >> > If you have only "b", r0 will not be chosen. Does that help? Or are >> > you generating this pattern from somewhere else where you put in r0? >> >> Mike, >> >> What happens if you leave out the "r" alternative? Does other code >> explicitly generate that pattern with r0? > > Sometimes, one of the passes after reload (usually -fgcse-after-reload) > decides > to redo the register allocation, and I would see a failure in building things > like Spec 2006. I have tried not putting the "r" in there, or using > base_reg_operand instead of gpc_reg_operand, but I still got failures.
This seems like a bug in those other passes that should be tracked down. Thanks, David
