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.
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
>
>>
