[Bug tree-optimization/97743] New: Failure to optimize boolean multiplication to select

[Bug tree-optimization/97743] New: Failure to optimize boolean multiplication to select

[gabravier at gmail dot com]

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

            Bug ID: 97743
           Summary: Failure to optimize boolean multiplication to select
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(bool b)
{
    return b * 743;
}

This can be optimized to `return b ? 743 : 0;`. This optimization is done by
LLVM, but not GCC.

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
          Component|tree-optimization           |middle-end
             Target|                            |x86_64-*-*

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
But is it really faster?

        movzbl  %dil, %eax
        imull   $743, %eax, %eax

vs.

        negb    %dil
        sbbl    %eax, %eax
        andl    $743, %eax

clang9 produces

        testl   %edi, %edi
        movl    $743, %eax              # imm = 0x2E7
        cmovel  %edi, %eax

more like a middle-end/RTL expansion transform, target dependent.

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Benchmarking shows at least on i9-7960X the multiplications to be faster -
0m0.493s for multiplication, 0m0.737s for ? 743 : 0 for 1 billion iterations in
a tight loop storing the result into memory.

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
imull on core & zen is 3-4 cycles latency (no idea if they special-case 0 or 1
values somehow, guess not).

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What about:
(-B)&743
Is that faster?

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> What about:
> (-B)&743
> Is that faster?

Never mind I see it was not :)

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What about:
        movzbl  %dil, %eax
        negl    %eax
        andl    $743, %eax

That would be 3 cycles, definitely better than the cmov case.  maybe one cycle
better than the imul case. It all depends on where the argument is coming from
really. If it was a set then we have these three choices:
int fm(int a, int d)
{
    int b = a == d;
    return b * 743;
}
int fc(int a, int d)
{
    return a==d ? 0 : 743;
}
int fand(int a, int d)
{
    int b = a == d;
    int t = -(b&1);
    return t & 743;
}

Producing:
fm:
        xorl    %eax, %eax
        cmpl    %esi, %edi
        sete    %al
        imull   $743, %eax, %eax
        ret
fc:
        xorl    %eax, %eax
        movl    $743, %edx
        cmpl    %esi, %edi
        cmovne  %edx, %eax
        ret
fand:
        xorl    %eax, %eax
        cmpl    %esi, %edi
        sete    %al
        negl    %eax
        andl    $743, %eax
        ret

For aarch64 we get:
fm:
        cmp     w0, w1
        mov     w0, 743
        cset    w1, eq
        mul     w0, w1, w0
        ret
fc:
        cmp     w0, w1
        mov     w0, 743
        csel    w0, w0, wzr, ne
        ret
fand:
        cmp     w0, w1
        mov     w0, 743
        csetm   w1, eq
        and     w0, w1, w0
        ret

For aarch64, the csel is faster as cset is just a csel but with increment.

For x86, It all depends on the cmov performance, I do think the neg/and case is
still faster than the imull case.

[Bug middle-end/97743] Failure to optimize boolean multiplication to select

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is really a dup of bug 68557.

*** This bug has been marked as a duplicate of bug 68557 ***