This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,rs6000] Add built-in function support for Power9 byte instructions


On Tue, Nov 15, 2016 at 11:05:07AM -0700, Kelvin Nilsen wrote:
> >> 	* config/rs6000/altivec.md (UNSPEC_CMPRB): New unspec value.
> >> 	(UNSPEC_CMPRB2): New unspec value.
> > 
> > I wonder if you really need both?  The number of arguments will tell
> > which is which, anyway?
> 
> I appreciate your preference to avoid proliferation of special-case
> unspec constants.  However, it is a not so straightforward to combine
> these two cases under the same constant value.  The issue is that though
> the two encoding conceptually represent different "numbers of
> arguments", the arguments are all packed inside of a 32-bit register.
> At the RTL level, it looks like the two different forms have the same
> number of arguments (the same number of register operands).  The
> difference is which bits serve relevant purposes within the incoming
> register operands.
> 
> So I'm inclined to keep this as is if that's ok with you.

Ah right, for some reason I thought the unspec had all the bounds as
separate args.  -ENOTENOUGHCOFFEE.

[ snip ]

> Thanks for catching this.  I think I got endian confusion inside my head
> while I was writing the above.  I will rewrite these comments, below also.

Note the ISA calls the bits in 32-bit registers 32..63, so that 63 is
the rightmost bit in all registers.

> > I wonder if we really need all these predicate expanders, if it wouldn't
> > be easier if the builtin handling code did the setb itself?
> > 
> 
> The reason it seems most "natural" to me use the expanders is because I
> need to introduce a temporary CR scratch register between expansion and
> insn matching.  Also, it seems that the *setb pattern may be of more
> general use in the future implementation of other built-in functions.
> I'm inclined to keep this as is, but if you still feel otherwise, I'll
> figure out how to avoid the expansion.

The code (in rs6000.c) expanding the builtin can create two insns directly,
so that you do not need to repeat this over and over in define_expands?


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]