[Bug middle-end/111126] New: Not always using czero.eqz

[Bug middle-end/111126] New: Not always using czero.eqz

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

            Bug ID: 111126
           Summary: Not always using czero.eqz
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: pinskia at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: riscv* (with zicond)

Take:
```
int f(bool a, int c)
{
  return a * c;
}

int f0(bool a, int c)
{
  return (-a) & c;
}

int f1(bool a, int c)
{
  return a ? c : 0;
}

int f3(int a, int b, int c)
{
  return (a == b) * c;
}
int g0(bool a, int c)
{
  return a ? 0 : c;
}
int g1(bool a, int c)
{
  a = !a;
  return a * c;
}
```

Currently for f, f0 we emit:
```
        neg     a0,a0
        and     a0,a0,a1
```

Which is good for riscv without zicond but with we should just get the same as
f1.

f1 we do we:
```
        czero.eqz       a0,a1,a0
```

though without zicond we get:
```
        snez    a5,a0
        neg     a5,a5
        and     a0,a1,a5
```
Notice the extra snez (note the above is because that is ifcvt.cc doing the
emitting).

This is all about what is the canonical form of bool ? a : 0.

[Bug middle-end/111126] Not always using czero.eqz

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-08-24

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Mine. requires both a gimple match.pd change and an expansion change.

[Bug middle-end/111126] Not always using czero.eqz

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|riscv* (with zicond)        |riscv* (with zicond),
                   |                            |loongarch*, mips*r6*
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
LoongArch and MIPS64r6 also have similar instructions.

[Bug middle-end/111126] Not always using czero.eqz

[rzinsly at ventanamicro dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

--- Comment #3 from Raphael M Zinsly <rzinsly at ventanamicro dot com> ---
Created attachment 57671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57671&action=edit
proposed patch

This is the same patch I posted in PR114277, it fixes this bug as well.

[Bug middle-end/111126] Not always using czero.eqz

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Raphael M Zinsly from comment #3)
> Created attachment 57671 [details]
> proposed patch
> 
> This is the same patch I posted in PR114277, it fixes this bug as well.

The question is which is more Canonical on gimple. the multiply or the
cond_expr.
I say the multiply.

Since the multiply is.
then  you just need to add the case to 
"/* Expand X*Y as X&-Y when Y must be zero or one.  */"
instead in expr.cc.

Though it does some costing which also needs/should be handled too.

[Bug middle-end/111126] Not always using czero.eqz

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111126

--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Multiply as a canonical form of a conditional move/zero seems fairly
non-obvious relative to a conditional expression.

But I don't mind going with consensus on a canonical form.  After all we just
need to define one.

The bigger question is fixing the expansion.

We can expand as a multiply, x&-y or with a conditional-move like sequence.