On Mon, Jul 22, 2024 at 7:41 PM Kewen.Lin <li...@linux.ibm.com> wrote:
>
> Hi Andrew,
>
> on 2024/7/23 08:09, Andrew Pinski wrote:
> > On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin <li...@linux.ibm.com> wrote:
> >>
> >> Hi,
> >>
> >> 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.
> >>
> >> 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?
> >
> > Just a quick FYI (I will be making the change and testing the change).
> > The optab names `andc` and `iorc` unfortunately do not work with
> > scalar modes since there are complex modes which start with c and are
> > combined with the scalar modes. So for an example a pattern named
> > `andcsi3` is not for the optab `andc` with the mode of si but rather
> > for `and` optab and for the mode `csi`. The same issue happens for
> > `iorc` too.
>
> ah, thanks for pointing out this! I guess a "_" can help, that is:
>
> OPTAB_D (andc_optab, "andc_$a3")
> OPTAB_D (iorc_optab, "iorc_$a3")
>
> but the downside is the code naming become different from "and$a3"
> and "ior$a3", so it seems better to use different names like what
> you proposed.
>
> > Thinking out loud on what names we should use instead; `andn` and
> > `iorn` might be ok? Does anyone else have any suggestions?
>
> FWIW, they look good to me.
Just FYI. I also noticed the powerpc backend could define these optabs
for scalars and would benefit for better code with the following
example (after I finish up my patches):
```
long f1(long a, long b)
{
a = ~0x4;
return a | ~b;
}
long f2(long a, long b)
{
a = ~0x4;
return a & ~b;
}
```
Thanks,
Andrew Pinski
>
> BR,
> Kewen
>
> >
> > Note I will also be adding the cond version of them since at least for
> > aarch64 SVE, bic (andc) can be conditional.
> >
> > Thanks,
> > Andrew Pinski
> >
> >>
>
>
