on 2024/7/24 06:53, Andrew Pinski wrote:
> 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;
> }
> ```
>
Yeah, andc/orc would be better, thanks for the heads up.
BR,
Kewen
