--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-23 20:48 ---
OK. Now mainline is a lot faster than 3.3 on this testcase.
3.3 takes more than 20 seconds
mainlines takes less than 3 seconds
Thanks Andrew!
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-23 19:18
---
I think I just fixed the compile time problem in this PR by the patch which I
committed for PR 17967,
Can you try again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-21 18:18 ---
The quadratic behavior of thread_jumps has been solved, but still
mainline is slower than 3.3 on this testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 17:02
---
Oh, you are right, maybe doing the forwarding before and try doing it after will fix
that and we will no
longer have to do while (thread_jumps()) either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 15:38 ---
Andrew,
Your algorithm would still present a quadratic behavior in the
following situation.
bb0<- a block with COND_EXPR only
| \
| \
| bb1 <- a block with COND_EXPR only
| | \
| | \
|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 14:44
---
Woops I have a fix for that and plus I also fixed an ICE I saw. I will attach a new
patch soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 14:24 ---
Andrew,
Regarding your patch, if we have exactly one basic block immediately preceding
EXIT_BLOCK_PTR, and that block happens to be a forwarder block, your algorithm
terminates without doing any further work.
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 13:29 ---
I should note that I used -O2 when I came up with "44%" in the initial
description of this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 13:26
---
I can get this down to (with a compiler at -O0):
tree CFG cleanup : 6.30 ( 6%) usr 0.02 ( 1%) sys 13.51 (10%) wall
I will submit a patch once I test it more on some other sources.
But I will atta
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 12:35 ---
Andrew, I did it in the hard way. :-)
void
foo (int a)
{
int b;
goto b1;
b4: return;
b3: if (a) { b = a; return; } else goto b4;
b2: if (a) { b = a; return; } else goto b3;
b1: if (a) { b = a; return
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:19
---
I also cannot think of a testcase where we have the reverse BB but it could happen.
Really we should
processoring by post-dom order which gives us the correct way to do this
transformation.
--
http:/
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 12:17
---
No this is not a regression (unless someone can find a testcase which says it is and I
cannot find a
testcase). See PR 17967 for a testcase which is a regression but thread_jumps has
nothing to do it
tho
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-13 12:11 ---
In this particular testcase, going through BBs in backwards does help
by cutting down the running time by about half, but I wonder if we can
create an identical testcase except that the order of BBs are reverse
--- Additional Comments From giovannibajo at libero dot it 2004-10-13 11:58
---
Is this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 04:14
---
The related testcase is filed under PR 17967.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17966
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-13 03:55
---
Confirmed, I have found a related testcase where we are slower than 3.3.3. This one
we are faster.
The way to fix this would be run on the BB backwards.
--
What|Removed
17 matches
Mail list logo