On Mon, Jul 01, 2024 at 04:36:44PM +0200, Richard Biener wrote:
> On Mon, Jul 1, 2024 at 8:17 AM Kewen.Lin <li...@linux.ibm.com> wrote:
> > As PR115659 shows, assuming c = x CMP y, there are some
> > folding chances for patterns r = c ? 0/z : z/-1:
> > - For r = c ? 0 : z, it can be folded into r = ~c & z.
> > - For r = c ? z : -1, it can be folded into r = ~c | z.
(!c instead of ~c, right?)
> > But BIT_AND/BIT_IOR applied on one BIT_NOT operand is a
> > compound operation, I'm not sure if each target with
> > vector capability have a single vector instruction for it,
> > if no, it's arguable to consider it always beats vector
> > selection (like vector constant gets hoisted or combined
> > and selection has same latency as normal logical operation).
> > So IMHO we probably need to query target with new optabs.
> > So this patch is to introduce new optabs andc, iorc and its
> > corresponding internal functions BIT_{ANDC,IORC} (looking
> > for suggestion for naming optabs and ifns), and if targets
> > defines such optabs for vector modes, it means targets
> > support these hardware insns and should be not worse than
> > vector selection. btw, the rs6000 changes are meant to
> > give an example for a target supporting andc/iorc.
> >
> > Does this sound reasonable?
>
> I think it's reasonable to have andc - there are quite some CPUs
> that have this op on GPRs as well I think, called andn (but I don't
> want to get into bike-shedding).
The usual names are and for a & b, andc for a & ~b, andc1 for ~a & b,
andcc for ~a & ~b, and an "n" in front of everything to complement the
result.
> A corresponding iorc is then
Sure. A full complement of *and* insns is equivalent to a full
complement of *or* insns, of course.
> a natural extension (likewise xorc).
xor and nxor (which is called "eqv" on powerpc) are all that can exist
of course :-)
> AVX512 has a very powerful
> vector ternlog (but no scalar andn).
We have that as well, "xxeval", a Power ISA v3.1 insn. It just has a
full 8-bit logic table as part of the opcode. But to fit that many bits
it is a prefixed insn.
Since day and age (well, the late 1990's) we have a full complement of
two-op logic insns for vectors, and since VSX exists (2010 or so?) for
all 64 vector regs we have since then. And it always was there for
integer regs, and for condition bits as well.
The two-op things are cheaper than the generic three-op thing, if that
is all that is needed.
> I was surprised to not see an existing optab for andn.
For most RTL stuff we can deal with it just fine using existing
define_insn etc. stuff. I have no idea if any of this is harder in
Gimple?
> So OK from my side in case there are no negative comments or
> bikeshedding on the name. I can't approve the rs6000 changes
> though.
But I can :-) I'll reply to just that. Thanks for handling this!
Segher
