[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Andrew Pinski --- Fixed.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 --- Comment #12 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b57bd27cb68fdbe5d9dcd571b1cb66f72b841290 commit r14-3036-gb57bd27cb68fdbe5d9dcd571b1cb66f72b841290 Author: Andrew Pinski Date: Sun Aug 6 13:57:35 2023 -0700 MATCH: [PR109959] `(uns <= 1) & uns` could be optimized to `uns == 1` I noticed while looking into some code generation of bitmap_single_bit_set_p, that sometimes: ``` if (uns > 1) return 0; return uns == 1; ``` Would not optimize down to just: ``` return uns == 1; ``` In this case, VRP likes to change `a == 1` into `(bool)a` if a has a range of [0,1] due to `a <= 1` side of the branch. We might end up with this similar code even without VRP, in the case of builtin-sprintf-warn-23.c (and Wrestrict.c), we had: ``` if (s < 0 || 1 < s) s = 0; ``` Which is the same as `s = ((unsigned)s) <= 1 ? s : 0`; So we should be able to catch that also. This adds 2 patterns to catch `(uns <= 1) & uns` and `(uns > 1) ? 0 : uns` and convert those into: `(convert) uns == 1`. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/109959 gcc/ChangeLog: * match.pd (`(a > 1) ? 0 : (cast)a`, `(a <= 1) & (cast)a`): New patterns. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/builtin-sprintf-warn-23.c: Remove xfail. * c-c++-common/Wrestrict.c: Update test and remove some xfail. * gcc.dg/tree-ssa/cmpeq-1.c: New test. * gcc.dg/tree-ssa/cmpeq-2.c: New test. * gcc.dg/tree-ssa/cmpeq-3.c: New test.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||626435.html --- Comment #11 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626435.html
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> +FAIL: c-c++-common/Wrestrict.c -Wc++-compat (test for excess errors)
> Excess errors:
This is just like the builtin-sprintf-warn-23.c xfail; well except there the
warning message was already correct.
Note if we change signed_range in gcc.dg/range.h to:
static inline ptrdiff_t signed_range (ptrdiff_t min, ptrdiff_t max)
{
ptrdiff_t val = signed_value ();
if (val < min || max < val)
__builtin_unreachable();
return val;
}
We get the same warning as we get with this patch. So I am definitely going to
add/change the dg-warning here because that will be the correct fix.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #9 from Andrew Pinski ---
+FAIL: c-c++-common/Wrestrict.c -Wc++-compat (test for excess errors)
Excess errors:
/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:684:3:
warning: 'strcpy' accessing 2 bytes at offsets [0, 1] and 0 overlaps between 1
and 2 bytes at offset [0, 1] [-Wrestrict]
T (8, "0", a + r, a); /* { dg-warning "accessing between 1 and 2 bytes at
offsets \\\[0, 1] and 0 overlaps up to 2 bytes at offset \\\[0, 1]" "strcpy" {
xfail *-*-*} } */
Looks like the dg-warning needs to be updated and the xfail removed.
we have:
```
strcpy (a+[0,1], a);
```
/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:863:3:
warning: 'strncpy' accessing 1 byte at offsets 0 and [0, 1] may overlap 1 byte
at offset 0 [-Wrestrict]
T ("0123", a, a + i, 1);
In this case a and a+[0,1] can overlap for strncpy even for size of 1.
/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:866:3:
warning: 'strncpy' accessing 2 bytes at offsets 0 and [0, 1] overlaps between 1
and 2 bytes at offset [0, 1] [-Wrestrict]
T ("0123", a, a + i, 2); /* { dg-warning "accessing 2 bytes at offsets 0
and \\\[0, 1] may overlap 1 byte at offset 1" "strncpy" { xfail *-*-* } } */
Just like the first case.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 --- Comment #8 from Andrew Pinski --- Created attachment 55696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55696=edit Patch which I am testing
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104296 --- Comment #7 from Andrew Pinski --- For the bothone: `(a > 1) ? 0 : a` could just be simplified to: `(cast)(a == 1)` For unsigned types. So: (simplify (cond (gt @0 integer_onep@1) integer_zerop (convert? @0)) (if (TYPE_UNSIGNED (TREE_TYPE (@0))) (convert (eq @0 @1)) ) ) Turns out the optional convert in the above will catch both cases.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > This is basically PR 102138 . Except it works at -O1 because the cast is pushed out of the phi by phiopt but the cast is the same as a & 1 here :(. For comment #0 we could just match this for unsigned type a_2(D) > 1 ? 0 : a_2(D) == a_2(D) <= 1 ? a_2(D) : 0 -> (unsigned)(a == 1) For comment #3 we need to pattern match this now: _7 = (_Bool) a_6(D); _9 = a_6(D) <= 1; _10 = _7 & _9;
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102138 --- Comment #5 from Andrew Pinski --- This is basically PR 102138 .
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-25
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 --- Comment #4 from Andrew Pinski --- Note the underlaying issue with VRP is similar to PR 109959 but it is about a slightly different optimization though.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
--- Comment #3 from Andrew Pinski ---
here is another related testcase but this was the exactly reduced one from
bitmap_single_bit_set_p :
```
_Bool f(unsigned a, int t)
{
void g(void);
if (t)
return 0;
g();
if (a > 1)
return 0;
return a == 1;
}
```
this should be optimized down to:
```
_Bool f(unsigned a, int t)
{
void g(void);
if (t)
return 0;
g();
return a == 1;
}
```
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 --- Comment #2 from Andrew Pinski --- I should note I found this while looking at code generation of bitmap_single_bit_set_p after a match pattern addition.
[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959 Andrew Pinski changed: What|Removed |Added Summary|`(a > 1) ? 0 : (a == 1)` is |`(a > 1) ? 0 : (a == 1)` is |not optimized when spelled |not optimized when spelled |out |out at -O2+ --- Comment #1 from Andrew Pinski --- I should say this at -O2. part of the reason is VRP changes `a == 1` to be `(bool)a` and then phiopt comes along and decides to factor out the conversion (phiopt did that even before my recent changes). at -O1, it is actually optimized during reassoc1 (because the above is not done) since GCC 7.
