https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124018
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2026-02-08
Status|UNCONFIRMED |NEW
Summary|Improve |Improve switch lowering for
|if-conversion/ifcombine of |ccmp and targets that store
|boolean values |cmp results not in flags
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
So it turns out this is switch lowering that turns it into the below gimple.
beginning to process the following SWITCH statement ((null):0) : -------
switch (type_5(D)) <default: <L6> [66.00%], case 0: <L5> [34.00%], case 4: <L5>
[34.00%], case 6: <L5> [34.00%]>
So I think we should just improve switch lowering here instead.
Before switch lowering:
```
<bb 2> [local count: 1073741824]:
switch (type_5(D)) <default: <L6> [66.00%], case 0: <L5> [34.00%], case 4:
<L5> [34.00%], case 6: <L5> [34.00%]>
<bb 3> [local count: 708669600]:
<L6>:
<bb 4> [local count: 1073741824]:
# _4 = PHI <1(2), 0(3)>
```
For this we should turn it (which is what LLVM does) into:
```
addi a1, a0, -6
andi a0, a0, -5
seqz a1, a1
seqz a0, a0
or a0, a0, a1
```
That is:
((type - 6) == 0) | ((type & -5) == 0)
Note making `81 >> _1` unconditional does introduce undefined behavior so I
doubt we want to allow that.
There is another bug report for another switch lowering issue too.
