public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/64541] New: .fre1 pass optimization failure
@ 2015-01-08 16:06 skvadrik at gmail dot com
2015-01-14 11:56 ` [Bug tree-optimization/64541] FRE " skvadrik at gmail dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: skvadrik at gmail dot com @ 2015-01-08 16:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
Bug ID: 64541
Summary: .fre1 pass optimization failure
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 34403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34403&action=edit
1.c 2.c 1.c.028t.esra 2.c.028t.esra 1.c.030t.fre1 2.c.030t.fre1 1.s 2.s
compile_gcc.sh
Files 1.c and 2.c in attach are equivalent from C/C++ standpoint:
$ diff 1.c 2.c
3c3,5
< return *(*q = ++*p);
---
> ++*p;
> *q = *p;
> return **p;
Compiled with gcc-5.0.0, disassembled with objdump (GNU Binutils) 2.24
(see full script compile_gcc.sh in attach).
For 1.c gcc generates better code than for 2.c
(compare 1.s vs 2.s in attach).
I looked at GIMPLE optimization dumps (-fdump-tree-all) and found that
up to *.029t.ealias pass dumps differ insignificantly (attached
*.028t.esra dumps as they are shorter), but .030t.fre1 pass fails to
reduce intermediate variable '_9' in the second case (attached *.030t.fre
dumps).
Looks like a bug in full redundancy elimination.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/64541] FRE pass optimization failure
2015-01-08 16:06 [Bug tree-optimization/64541] New: .fre1 pass optimization failure skvadrik at gmail dot com
@ 2015-01-14 11:56 ` skvadrik at gmail dot com
2015-01-14 12:00 ` rguenther at suse dot de
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: skvadrik at gmail dot com @ 2015-01-14 11:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
--- Comment #2 from Ulya <skvadrik at gmail dot com> ---
> we have to assume that p == q and thus the store to *q invalidates the previously load *p
I see.
It seemed to me from GIMPLE dumps that both cases are equally easy to optimize,
perhaps I'm missing something.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/64541] FRE pass optimization failure
2015-01-08 16:06 [Bug tree-optimization/64541] New: .fre1 pass optimization failure skvadrik at gmail dot com
2015-01-14 11:56 ` [Bug tree-optimization/64541] FRE " skvadrik at gmail dot com
@ 2015-01-14 12:00 ` rguenther at suse dot de
2015-01-14 12:03 ` skvadrik at gmail dot com
2021-12-15 21:43 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenther at suse dot de @ 2015-01-14 12:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 14 Jan 2015, skvadrik at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
>
> --- Comment #2 from Ulya <skvadrik at gmail dot com> ---
> > we have to assume that p == q and thus the store to *q invalidates the previously load *p
>
> I see.
> It seemed to me from GIMPLE dumps that both cases are equally easy to optimize,
> perhaps I'm missing something.
1:
_6 = *p_2(D);
*q_7(D) = _6;
_9 = *q_7(D);
_10 = *_9;
it's easy to see that the load _9 = *q_7(D) results in _6.
2:
*p_2(D) = _4;
_6 = *p_2(D);
*q_7(D) = _6;
_9 = *p_2(D);
_10 = *_9;
not so much here for the load _9 = *p_2(D) as I explained
(the store *q_7(D) = _6 aliases it)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/64541] FRE pass optimization failure
2015-01-08 16:06 [Bug tree-optimization/64541] New: .fre1 pass optimization failure skvadrik at gmail dot com
2015-01-14 11:56 ` [Bug tree-optimization/64541] FRE " skvadrik at gmail dot com
2015-01-14 12:00 ` rguenther at suse dot de
@ 2015-01-14 12:03 ` skvadrik at gmail dot com
2021-12-15 21:43 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: skvadrik at gmail dot com @ 2015-01-14 12:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
--- Comment #4 from Ulya <skvadrik at gmail dot com> ---
Ah! Now I see the problem, thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug tree-optimization/64541] FRE pass optimization failure
2015-01-08 16:06 [Bug tree-optimization/64541] New: .fre1 pass optimization failure skvadrik at gmail dot com
` (2 preceding siblings ...)
2015-01-14 12:03 ` skvadrik at gmail dot com
@ 2021-12-15 21:43 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-15 21:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64541
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-12-15 21:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-08 16:06 [Bug tree-optimization/64541] New: .fre1 pass optimization failure skvadrik at gmail dot com
2015-01-14 11:56 ` [Bug tree-optimization/64541] FRE " skvadrik at gmail dot com
2015-01-14 12:00 ` rguenther at suse dot de
2015-01-14 12:03 ` skvadrik at gmail dot com
2021-12-15 21:43 ` 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).