[Bug tree-optimization/112645] New: missed-optimization: cswitch optimization missed in nested if-statement

[Bug tree-optimization/112645] New: missed-optimization: cswitch optimization missed in nested if-statement

[goon.pri.low at gmail dot com]

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

            Bug ID: 112645
           Summary: missed-optimization: cswitch optimization missed in
                    nested if-statement
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

These two functions should theoretically generate the same code, though the
second one uses a constant array.

int a(int v) {
    switch (v & 2) {
    case 0: //0x
        switch(v & 1) {
        case 0: //00
            return 643;
        case 1: //01
            return 223;
        }
    case 2: //1x
        switch (v & 1) {
        case 0: //10
            return 444;
        case 1: //11
            return 532;
        }
    }
}

a:
        test    dil, 2
        je      .L7
        and     edi, 1
        cmp     edi, 1
        sbb     eax, eax
        and     eax, -88
        add     eax, 532
        ret
.L7:
        and     edi, 1
        cmp     edi, 1
        sbb     eax, eax
        and     eax, 420
        add     eax, 223
        ret

int b(int v) {
    switch (v & 3) {
    case 0: //00
        return 643;
    case 1: //01
        return 223;
    case 2: //10
        return 444;
    case 3: //11
        return 532;
    }
}

b:
        and     edi, 3
        mov     eax, 643
        sub     edi, 1
        cmp     edi, 2
        ja      .L8
        mov     eax, DWORD PTR CSWTCH.2[0+rdi*4]
.L8:
        ret
CSWTCH.2:
        .long   223
        .long   444
        .long   532

Additionally while testing this, I found this function which should just use a
simple binary and

int c(int v) {
    switch (v & 3) {
    case 0:
        return 0;
    case 1:
        return 1;
    case 2:
        return 2;
    case 3:
        return 3;
    }
}

c:
        mov     eax, edi
        and     eax, 3
        lea     edx, [rax-1]
        cmp     edx, 3
        mov     edx, 0
        cmovnb  eax, edx
        ret

though has an unnecessary comparison and conditional move?

[Bug tree-optimization/112645] missed-optimization: cswitch optimization missed in nested if-statement

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-11-21
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I guess for the first testcase we're missing a "switch-merging"
transform.  For the last one we do

Linear transformation with A = 1 and B = 0
...
  <bb 2> :
  _1 = v_3(D) & 3;
  _6 = (unsigned int) _1;
  _7 = _6 + 4294967295;
  if (_7 <= 2)
    goto <bb 4>; [INV]
  else
    goto <bb 3>; [INV]

  <bb 3> :
<L7>:
  _9 = 0;
  goto <bb 5>; [100.00%]

  <bb 4> :
<L8>:
  _4 = (unsigned int) _1;
  _5 = _1;

  <bb 5> :
  # _2 = PHI <_5(4), _9(3)>

possibly because we earlier optimize the switch to

    switch (v & 3) {
    default:
        return 0;
    case 1:
        return 1;
    case 2:
        return 2;
    case 3:
        return 3;
    }

and fail to recover.

[Bug tree-optimization/112645] missed-optimization: cswitch optimization missed in nested if-statement

[goon.pri.low at gmail dot com]

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

--- Comment #2 from gooncreeper <goon.pri.low at gmail dot com> ---
I am going to move the second problem to it's own bug since I realize it
actually quite a different problem, and deserves it's own thread of discussion.