[PATCH], Add power9 support to GCC, patch #5 (ISA 3.0 fusion)

David Edelsohn dje.gcc@gmail.com
Mon Nov 9 22:33:00 GMT 2015


On Mon, Nov 9, 2015 at 2:17 PM, Michael Meissner
<meissner@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
>> <segher@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



More information about the Gcc-patches mailing list