--- Comment #15 from jingyu at google dot com 2010-05-13 18:09 ---
Patch was committed to trunk (4.6) r158138.
Resolved.
--
jingyu at google dot com changed:
What|Removed |Added
--- Comment #14 from jingyu at gcc dot gnu dot org 2010-04-08 18:17 ---
Subject: Bug 42720
Author: jingyu
Date: Thu Apr 8 18:16:57 2010
New Revision: 158138
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158138
Log:
Fix a problematic logic at unswitch-loops pass.
2010-04-07
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-02-07 20:28
---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jingyu at google dot com 2010-02-02 23:57 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
Zdenek,
I did dejagnu tests on your patch. It gave no regression on
--target_board=arm-sim/thumb.
Do you think this patch will be
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-30 10:59 ---
The interesting thing is that the empty loop is not removed by
the control-dependent DCE pass that follows the 2nd VRP.
This happens because
bb 3:
if (obj_7(D) != 0B)
goto bb 5;
else
goto bb 4;
bb 4:
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-30 11:00 ---
Oh, and Zdenek might have an idea about the condition simplification in
unswitching.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2010-01-30 12:01 ---
(In reply to comment #7)
Oh, and Zdenek might have an idea about the condition simplification in
unswitching.
I agree that some of the checks in tree_unswitch_single_loop are badly placed
-- it does not make
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-30 16:06 ---
(In reply to comment #6)
The interesting thing is that the empty loop is not removed by
the control-dependent DCE pass that follows the 2nd VRP.
This happens because
bb 3:
if (obj_7(D) != 0B)
goto
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-30 16:14 ---
That CD-DCE stuff has by now deviated so far from the text book
implementation that I don't recognize it anymore at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
--- Comment #11 from jingyu at google dot com 2010-01-30 23:33 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
I agree that some of the checks in tree_unswitch_single_loop are badly placed
-- it does not make sense to check them repeatedly
--- Comment #1 from jingyu at google dot com 2010-01-29 23:33 ---
The problem also exists on non-FDO use. So I changed the title of the bug.
Since unswitch-loop is set at -O3, I give -O3 to the command line. Parameter
max-unswitch-level means we only do unswitch-loop at most once.
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-29 23:38 ---
On x86, the empty loop is removed at -O3 on the tree level:
bb 3:
if (obj_7(D) != 0B)
goto bb 4;
else
goto bb 5;
bb 4:
# i_18 = PHI 0(3), i_20(4)
# s_23 = PHI 0(3), s_2(4)
obj.0_8 = (int)
--- Comment #3 from jingyu at google dot com 2010-01-29 23:59 ---
You must set --param max-unswitch-level=0 to trigger the bug in non-FDO use.
I just tried gcc-4.2.4 on X86 platform. The problem exists.
$ gcc loop.cpp -O3 --param max-unswitch-level=0 -m32 -S
testl %eax,
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-30 00:05 ---
(In reply to comment #3)
You must set --param max-unswitch-level=0 to trigger the bug in non-FDO use.
So the problem is really if (optimize_loop_for_size_p (loop)) . I think you
need to figure out why that is
--- Comment #5 from jingyu at google dot com 2010-01-30 00:21 ---
So the problem is really if (optimize_loop_for_size_p (loop)) . I think you
need to figure out why that is returning true.
That's because after unswitch-loop, one copy of the loop becomes cold. Let's
look at loop.cpp.
15 matches
Mail list logo
