public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
@ 2023-07-12 7:25 pinskia at gcc dot gnu.org
2023-07-12 7:26 ` [Bug tree-optimization/110637] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-12 7:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
Bug ID: 110637
Summary: (type)(zeroonep !=/== 0) should be optimized as
(type)zeroonep/zeroonep^1 earlier than vrp
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int t)
{
t &= 1;
return t != 0;
}
```
Currently this only gets optimized at -O2 (due to VRP) to:
_4 = t_1(D) & 1;
return _4;
Likewise for:
```
int g(int t)
{
t &= 1;
return t == 0;
}
```
This was originally how I was going to solve PR 110539 but when we should
optimize to those gets in the way of other optimizations so I decided to fix PR
110539 a different way.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
2023-07-12 7:25 [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp pinskia at gcc dot gnu.org
@ 2023-07-12 7:26 ` pinskia at gcc dot gnu.org
2023-07-12 8:06 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-07-12 7:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-07-12
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623881.html and the
reply.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
2023-07-12 7:25 [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp pinskia at gcc dot gnu.org
2023-07-12 7:26 ` [Bug tree-optimization/110637] " pinskia at gcc dot gnu.org
@ 2023-07-12 8:06 ` rguenth at gcc dot gnu.org
2023-12-11 15:56 ` cvs-commit at gcc dot gnu.org
2023-12-11 15:58 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-07-12 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Maybe zero_one_valued_p needs a
(match zero_one_valued_p
(bit_and @0 integer_onep))
? (hopefully for signed 1-bit precision that doesn't match)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
2023-07-12 7:25 [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp pinskia at gcc dot gnu.org
2023-07-12 7:26 ` [Bug tree-optimization/110637] " pinskia at gcc dot gnu.org
2023-07-12 8:06 ` rguenth at gcc dot gnu.org
@ 2023-12-11 15:56 ` cvs-commit at gcc dot gnu.org
2023-12-11 15:58 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-11 15:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:
https://gcc.gnu.org/g:85c5efcffed19ca6160eeecc2d4faebd9fee63aa
commit r14-6420-g85c5efcffed19ca6160eeecc2d4faebd9fee63aa
Author: Andrew Pinski <quic_apinski@quicinc.com>
Date: Sat Nov 11 15:54:10 2023 -0800
MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one type are
the same
When I moved two_value to match.pd, I removed the check for the {0,+-1}
as I had placed it after the {0,+-1} case for cond in match.pd.
In the case of {0,+-1} and non boolean, before we would optmize those
case to just `(convert)a` but after we would get `(convert)(a != 0)`
which was not handled anyways to just `(convert)a`.
So this adds a pattern to match `(convert)(zeroone != 0)` and simplify
to `(convert)zeroone`.
Also this optimizes (convert)(zeroone == 0) into (zeroone^1) if the
type match. Removing the opposite transformation from fold.
The opposite transformation was added with
https://gcc.gnu.org/pipermail/gcc-patches/2006-February/190514.html
It is no longer considered the canonicalization either, even VRP will
transform it back into `(~a) & 1` so removing it is a good idea.
Note the testcase pr69270.c needed a slight update due to not matching
exactly a scan pattern, this update makes it more robust and will match
before and afterwards and if there are other changes in this area too.
Note the testcase gcc.target/i386/pr110790-2.c needs a slight update
for better code generation in LP64 bit mode.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/111972
PR tree-optimization/110637
* match.pd (`(convert)(zeroone !=/== CST)`): Match
and simplify to ((convert)zeroone){,^1}.
* fold-const.cc (fold_binary_loc): Remove
transformation of `(~a) & 1` and `(a ^ 1) & 1`
into `(convert)(a == 0)`.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr110637-1.c: New test.
* gcc.dg/tree-ssa/pr110637-2.c: New test.
* gcc.dg/tree-ssa/pr110637-3.c: New test.
* gcc.dg/tree-ssa/pr111972-1.c: New test.
* gcc.dg/tree-ssa/pr69270.c: Update testcase.
* gcc.target/i386/pr110790-2.c: Update testcase.
* gcc.dg/fold-even-1.c: Removed.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
2023-07-12 7:25 [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp pinskia at gcc dot gnu.org
` (2 preceding siblings ...)
2023-12-11 15:56 ` cvs-commit at gcc dot gnu.org
@ 2023-12-11 15:58 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-11 15:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.
We decided that if the types don't match, we should keep around the `== 0` .
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-12-11 15:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-12 7:25 [Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp pinskia at gcc dot gnu.org
2023-07-12 7:26 ` [Bug tree-optimization/110637] " pinskia at gcc dot gnu.org
2023-07-12 8:06 ` rguenth at gcc dot gnu.org
2023-12-11 15:56 ` cvs-commit at gcc dot gnu.org
2023-12-11 15:58 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).