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. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
