public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/64992] New: More optimize opportunity
@ 2015-02-10 3:01 ishiura-compiler at ml dot kwansei.ac.jp
2015-02-10 10:18 ` [Bug tree-optimization/64992] " rguenth at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: ishiura-compiler at ml dot kwansei.ac.jp @ 2015-02-10 3:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Bug ID: 64992
Summary: More optimize opportunity
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
The two programs (A.c) and (B.c) only differ by one line (marked by "//
<---HERE"),
where (B.c) simply replace local variable b by its initial value 2U.
The code (A.s) for (A.c) is less optimized than (B.s) for (B.c).
(org.c)
int main (void)
{
volatile int a = -1;
unsigned int b = 2U;
int c = a + 0;
unsigned d = b * (1 == c); //<---HERE
if (c == -1) ;
else __builtin_abort();
if (d == 0U) ;
else __builtin_abort();
return 0;
}
(opt.c)
int main (void)
{
volatile int a = -1;
unsigned int b = 2U;
int c = a + 0;
unsigned d = 2U * (1 == c); //<---HERE
if (c == -1) ;
else __builtin_abort();
if (d == 0U) ;
else __builtin_abort();
return 0;
}
(org.s)
main:
.LFB0:
.cfi_startproc
subq $24, %rsp
.cfi_def_cfa_offset 32
xorl %eax, %eax
movl $-1, 12(%rsp)
movl 12(%rsp), %edx
cmpl $1, %edx
sete %al
addl %eax, %eax
cmpl $-1, %edx
jne .L3
testl %eax, %eax
jne .L3
addq $24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L3:
.cfi_restore_state
call abort
.cfi_endproc
.LFE0:
.size main, .-main
.section .text.unlikely
.LCOLDE0:
.section .text.startup
.LHOTE0:
.ident "GCC: (GNU) 5.0.0 20150205 (experimental)"
.section .note.GNU-stack,"",@progbits
(opt.s)
main:
.LFB0:
.cfi_startproc
subq $24, %rsp
.cfi_def_cfa_offset 32
movl $-1, 12(%rsp)
movl 12(%rsp), %eax
cmpl $-1, %eax
jne .L5
xorl %eax, %eax
addq $24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L5:
.cfi_restore_state
call abort
.cfi_endproc
.LFE0:
.size main, .-main
.section .text.unlikely
.LCOLDE0:
.section .text.startup
.LHOTE0:
.ident "GCC: (GNU) 5.0.0 20150205 (experimental)"
.section .note.GNU-stack,"",@progbits
$ x86_64-unknown-linux-gnu-gcc-5.0.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/iwatsuji/gcc/configure
--prefix=/usr/local/x86_64-tools/gcc-5.0.0/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 5.0.0 20150205 (experimental) (GCC)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
@ 2015-02-10 10:18 ` rguenth at gcc dot gnu.org
2015-02-15 5:15 ` ishiura-compiler at ml dot kwansei.ac.jp
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-02-10 10:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2015-02-10
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
That is simply because you declared b volatile and thus b may be zero HERE.
Not sure what you are expecting?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
2015-02-10 10:18 ` [Bug tree-optimization/64992] " rguenth at gcc dot gnu.org
@ 2015-02-15 5:15 ` ishiura-compiler at ml dot kwansei.ac.jp
2015-02-15 23:32 ` ishiura-compiler at ml dot kwansei.ac.jp
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ishiura-compiler at ml dot kwansei.ac.jp @ 2015-02-15 5:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #3 from Ishiura Lab Compiler Team <ishiura-compiler at ml dot kwansei.ac.jp> ---
Looking only from outside, the two programs are virtually equal, so we
just wondered what hinders the optimization on one of the programs.
The Optimization on "opt.c" seems very strong, so we think it would be
nice if the same transformation would work on "org.c."
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
2015-02-10 10:18 ` [Bug tree-optimization/64992] " rguenth at gcc dot gnu.org
2015-02-15 5:15 ` ishiura-compiler at ml dot kwansei.ac.jp
@ 2015-02-15 23:32 ` ishiura-compiler at ml dot kwansei.ac.jp
2021-11-29 3:51 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: ishiura-compiler at ml dot kwansei.ac.jp @ 2015-02-15 23:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #4 from Ishiura Lab Compiler Team <ishiura-compiler at ml dot kwansei.ac.jp> ---
FYI, clang-3.6 -O3 seems to do the same optimization on "org.c" as well as on
"opt.c."
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (2 preceding siblings ...)
2015-02-15 23:32 ` ishiura-compiler at ml dot kwansei.ac.jp
@ 2021-11-29 3:51 ` pinskia at gcc dot gnu.org
2021-11-30 22:08 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-29 3:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The missed optimization is:
int f(int c)
{
unsigned t = c == 1;
t <<= 1;
return t == 0;
}
int f1(int c)
{
unsigned t = c == 1;
return ((int)t) <= 0;
}
That is (t << 1) == 0 should be convert into either:
(t & 0x7fffffff) or ((int)t) <= 0
Though the (semi more) general case is:
(for shift (lshift rshift)
(for eqne (eq ne)
(simplify
(eqne (shift @0 INTEGER_CST@1) integer_zerop@2)
(with
{
mask = ...
}
(eqne (bit_and @0 { mask; }) @2)))))
And then the mask bit_and neeq to gtle
And then the rest will just work
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (3 preceding siblings ...)
2021-11-29 3:51 ` pinskia at gcc dot gnu.org
@ 2021-11-30 22:08 ` pinskia at gcc dot gnu.org
2021-11-30 22:18 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-30 22:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note for rotate it is as simple as:
(for cmp (eq ne)
(simplify
(cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2)
(cmp @0 (rotate @2 @1))))
Let me see if that is already there or not and test that one out.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (4 preceding siblings ...)
2021-11-30 22:08 ` pinskia at gcc dot gnu.org
@ 2021-11-30 22:18 ` pinskia at gcc dot gnu.org
2021-12-01 5:53 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-30 22:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #9)
> Note for rotate it is as simple as:
> (for cmp (eq ne)
> (simplify
> (cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2)
> (cmp @0 (rotate @2 @1))))
>
> Let me see if that is already there or not and test that one out.
Well it is already done (and I messed up the above which should have been
invrotote anyways):
/* (X >>r C1) cmp C2 may simplify to X cmp C3. */
(simplify
(cmp (rotate @0 INTEGER_CST@1) INTEGER_CST@2)
(cmp @0 { const_binop (invrot, TREE_TYPE (@0), @2, @1); }))
So it is just lshift and rshift that need to be implemented.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (5 preceding siblings ...)
2021-11-30 22:18 ` pinskia at gcc dot gnu.org
@ 2021-12-01 5:53 ` pinskia at gcc dot gnu.org
2022-08-15 16:41 ` cvs-commit at gcc dot gnu.org
2022-09-10 21:10 ` roger at nextmovesoftware dot com
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-01 5:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the latest patch for PR 98954 fixes this one.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (6 preceding siblings ...)
2021-12-01 5:53 ` pinskia at gcc dot gnu.org
@ 2022-08-15 16:41 ` cvs-commit at gcc dot gnu.org
2022-09-10 21:10 ` roger at nextmovesoftware dot com
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-08-15 16:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:
https://gcc.gnu.org/g:418b71c0d535bf91df78bad2e198c57934682eaa
commit r13-2048-g418b71c0d535bf91df78bad2e198c57934682eaa
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Mon Aug 15 17:39:47 2022 +0100
PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean.
This patch resolves both PR tree-optimization/64992 and PR
tree-optimization/98956 which are missed optimization enhancement
request, for which Andrew Pinski already has a proposed solution
(related to a fix for PR tree-optimization/98954). Yesterday,
I proposed an alternate improved patch for PR98954, which although
superior in most respects, alas didn't address this case [which
doesn't include a BIT_AND_EXPR], hence this follow-up fix.
For many functions, F(B), of a (zero-one) Boolean value B, the
expression F(B) != 0 can often be simplified to just B. Hence
"(B * 5) != 0" is B, "-B != 0" is B, "bswap(B) != 0" is B,
"(B >>r 3) != 0" is B. These are all currently optimized by GCC,
with the strange exception of left shifts by a constant (possibly
due to the undefined/implementation defined behaviour when the
shift constant is larger than the first operand's precision).
This patch adds support for this particular case, when the shift
constant is valid.
2022-08-15 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR tree-optimization/64992
PR tree-optimization/98956
* match.pd (ne (lshift @0 @1) 0): Simplify (X << C) != 0 to X
when X is zero_one_valued_p and the shift constant C is valid.
(eq (lshift @0 @1) 0): Likewise, simplify (X << C) == 0 to !X
when X is zero_one_valued_p and the shift constant C is valid.
gcc/testsuite/ChangeLog
PR tree-optimization/64992
* gcc.dg/pr64992.c: New test case.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug tree-optimization/64992] More optimize opportunity
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
` (7 preceding siblings ...)
2022-08-15 16:41 ` cvs-commit at gcc dot gnu.org
@ 2022-09-10 21:10 ` roger at nextmovesoftware dot com
8 siblings, 0 replies; 10+ messages in thread
From: roger at nextmovesoftware dot com @ 2022-09-10 21:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger at nextmovesoftware dot com
Status|ASSIGNED |RESOLVED
Target Milestone|--- |13.0
Resolution|--- |FIXED
--- Comment #13 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-09-10 21:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-10 3:01 [Bug tree-optimization/64992] New: More optimize opportunity ishiura-compiler at ml dot kwansei.ac.jp
2015-02-10 10:18 ` [Bug tree-optimization/64992] " rguenth at gcc dot gnu.org
2015-02-15 5:15 ` ishiura-compiler at ml dot kwansei.ac.jp
2015-02-15 23:32 ` ishiura-compiler at ml dot kwansei.ac.jp
2021-11-29 3:51 ` pinskia at gcc dot gnu.org
2021-11-30 22:08 ` pinskia at gcc dot gnu.org
2021-11-30 22:18 ` pinskia at gcc dot gnu.org
2021-12-01 5:53 ` pinskia at gcc dot gnu.org
2022-08-15 16:41 ` cvs-commit at gcc dot gnu.org
2022-09-10 21:10 ` roger at nextmovesoftware dot com
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).