[Bug middle-end/112098] New: suboptimal optimization of inverted bit extraction

[Bug middle-end/112098] New: suboptimal optimization of inverted bit extraction

[bruno at clisp dot org]

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

            Bug ID: 112098
           Summary: suboptimal optimization of inverted bit extraction
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bruno at clisp dot org
  Target Milestone: ---

gcc optimizes quite well a bit extraction such as

---------------------- foo.c ----------------------
unsigned int foo (unsigned int x)
{
  return (x & 0x200 ? 0x10 : 0);
}
---------------------------------------------------

$ gcc -O2 -S foo.c && cat foo.s
...
        shrl    $5, %eax
        andl    $16, %eax
...
That is perfect: 2 arithmetic instructions.

However, for the inverted bit extraction
====================== foo.c ======================
unsigned int foo (unsigned int x)
{
  return (x & 0x200 ? 0 : 0x10);
}
===================================================

the resulting code has 4 arithmetic instructions:

$ gcc -O2 -S foo.c && cat foo.s
...
        shrl    $9, %eax
        xorl    $1, %eax
        andl    $1, %eax
        sall    $4, %eax
...

Very clearly, the last shift instruction could be saved by transforming this
code to

...
        shrl    $5, %eax
        xorl    $16, %eax
        andl    $16, %eax
...

clang 16 even replaces the "xorl $16, %eax" instruction with a "notl %eax". So,
the optimal instruction sequence is one of
...
        shrl    $5, %eax
        notl    %eax
        andl    $16, %eax
...
or
...
        notl    %eax
        shrl    $5, %eax
        andl    $16, %eax
...

$ gcc --version
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.

This is for x86_64. But similar optimization opportunities exist for other CPUs
as well.
For example, arm:

...
        lsr     r0, r0, #9
        eor     r0, r0, #1
        and     r0, r0, #1
        lsl     r0, r0, #4
...
which can be optimized to
...
        lsr     r0, r0, #5
        eor     r0, r0, #16
        and     r0, r0, #16
...

Or for sparc64:

...
        and     %o0, 512, %o0
        cmp     %g0, %o0
        subx    %g0, -1, %o0
        sll     %o0, 4, %o0
        jmp     %o7+8
         srl    %o0, 0, %o0
...
which can be optimized to
...
        xnor    %g0, %o0, %o0
        srl     %o0, 5, %o0
        jmp     %o7+8
         and    %o0, 16, %o0
...

[Bug middle-end/112098] suboptimal optimization of inverted bit extraction

[bruno at clisp dot org]

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

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
The code that gets executed inside gcc is maybe the one mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907#c2 .

[Bug middle-end/112098] suboptimal optimization of inverted bit extraction

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
   Last reconfirmed|                            |2023-10-26
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Mine.
The problem is more simplified than that.
We recognize: `(A & C) != 0 ? D : 0` But not `(A & C) == 0 ? D : 0`

Also the order of match causes issues for

unsigned int foo_ (unsigned int x)
{
  int t = x & 0x200;
  if (t) return 0x10;
  return 0;
}

/* A few simplifications of "a ? CST1 : CST2". */

And a few other issues too.

[Bug middle-end/112098] suboptimal optimization of inverted bit extraction

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Trying 6, 7, 8 -> 9:
    6: {r105:SI=r108:SI 0>>0x9;clobber flags:CC;}
      REG_DEAD r108:SI
      REG_UNUSED flags:CC
    7: {r106:SI=r105:SI&0x1;clobber flags:CC;}
      REG_DEAD r105:SI
      REG_UNUSED flags:CC
    8: {r107:SI=r106:SI^0x1;clobber flags:CC;}
      REG_DEAD r106:SI
      REG_UNUSED flags:CC
    9: {r103:SI=r107:SI<<0x4;clobber flags:CC;}
      REG_DEAD r107:SI
      REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
        (set (reg:SI 103)
            (and:SI (lshiftrt:SI (xor:SI (reg:SI 108)
                        (const_int 512 [0x200]))
                    (const_int 5 [0x5]))
                (const_int 16 [0x10])))
        (clobber (reg:CC 17 flags))
    ])


The xor here maybe should have been not. But I can't remember if we allow 4->3
combining or just 4->2.