On Fri, Sep 21, 2012 at 10:11 PM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > Currently, the register predicates allow a subreg of anything, > including memory or the wrong kind of register. Most other ports > do not allow this. As far as I can see, this doesn't help the > compiler generate better code, potentially the opposite. > > This also causes a problem for my (upcoming) add-with-carry work. > The patterns for the add-with-carry instructions are each a parallel > of two sets, one of a GPR and one of CA. Sometimes one of those > sets isn't used, for example for most ADDE instructions, and combine > will try e.g. (set (reg:P xxx) (reg:P CA_REGNO)) which fails > because that isn't an existing instruction. But when it tries > (set (reg:SI xxx) (subreg:SI (reg:DI CA_REGNO) 4)) it currently > succeeds, because it looks like movsi2; but of course it ICEs > later on. > > This patch tightens the register predicates to only allow a subreg > of the kind of registers the predicates allows. The generated code > for e.g. gpc_reg_operand looks a bit worse, but benchmarking shows > it to be a wash (average of three runs on combine.ii: original > 0m13.014s, patched 0m13.003s). > > Tested on powerpc64-linux --enable-languages=c,c++,fortran; > no regressions. Okay to apply? > > > Segher > > > 2012-09-21 Segher Boessenkool <seg...@kernel.crashing.org> > > gcc/ > * config/rs6000/predicates.md (altivec_register_operand, > vsx_register_operand, vfloat_operand, vint_operand, > vlogical_operand, gpc_reg_operand, cc_reg_operand, > cc_reg_not_cr0_operand, cc_reg_not_micro_cr0_operand): > If op is a SUBREG, consider its SUBREG_REG instead.
Okay. Thanks, David
