On Fri, Aug 13, 2021 at 02:07:25PM -0400, David Edelsohn wrote:
> On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
> <seg...@kernel.crashing.org> wrote:
> >
> > On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> > > On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
> > > <seg...@kernel.crashing.org> wrote:
> > > >
> > > > On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> > > > > I noticed that the xxeval built-in function used the
> > > > > altivec_register_operand
> > > > > predicate. Since it takes vsx registers, this might force the
> > > > > register
> > > > > allocate to issue a move when it could use a traditional floating
> > > > > point
> > > > > register. This patch fixes that.
> > > >
> > > > Why register_operand instead of gpc_reg_operand? The former allows
> > > > subregs of memory, likely not what you want here (and not in other
> > > > rs6000 pattern that currently use it, either).
> > >
> > > Because it's consistent with the other patterns.
> >
> > Not with the vast majority of other patterns, no.
>
> For vector operands in altivec.md, if the predicates do not use
> altivec_register_operand, they use register_operand, not
> gpc_reg_operand. Mike's change is consistent with the rest of the
> altivec.md file.
>
> Maybe the predicates for those patterns should be changed. Maybe that
> change would be an improvement.
>
> Your statement about the vast majority of patterns is wrong with
> respect to altivec.md.
There is nothing about that file that makes it any different for this?
Anyway, the numbers:
gpc_reg_operand register_operand
config/rs6000/altivec.md 11 760
config/rs6000/crypto.md 0 14
config/rs6000/darwin.md 25 1
config/rs6000/dfp.md 71 3
config/rs6000/fusion.md 349 0
config/rs6000/htm.md 10 0
config/rs6000/mma.md 4 0
config/rs6000/pcrel-opt.md 8 0
config/rs6000/rs6000.md 1105 116
config/rs6000/sync.md 0 3
config/rs6000/vector.md 0 29
config/rs6000/vsx.md 102 122
Segher
