On Mon, Nov 25, 2019 at 05:40:02PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > > This patch generates PADDI to add 34-bit immediate constants on the
> > > 'future'
> > > system, and prevents such adds from being split.
> >
> > I don't see that last part? Is that a remnant of a previous version of
> > the patch?
>
> This falls out of the add_operand change.
<snip>
> Since non_add_cint_operand is defined as:
>
> (define_predicate "non_add_cint_operand"
> (and (match_code "const_int")
> (not (match_operand 0 "add_operand"))))
>
> It follows that if add_operand now allows a 34-bit constant when -mcpu=future,
> that non_add_cint_operand will return 0, and the add will not be split.
Right, so write that please ("changes add_operand"), not some random
consequence of that change.
> > > * config/rs6000/rs6000.md (add<mode>3): Add support for PADDI.
> >
> > (add<mode>3 for GPR): etc.
> >
> > We have six things all called add<mode>3 (VI2, DDTD, SDI, SFDF, IEEE128,
> > VEC_F). Erm.
> >
> > Wait, this is called *add<mode>3, not add<mode>3.
>
> Yeah, I usually add the iterator part to identify which one was changed.
No, the asterisk is part of the name, that's my point. And yes please
say what the iterator is.
Segher
