--- Comment #14 from law at redhat dot com 2006-03-30 17:15 ---
Just a note on the compile-time regressions for tramp3d...
After fixing the timevars it was pretty clear that it isn't the cprop code
itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in
operand
--- Comment #13 from law at redhat dot com 2006-03-28 19:13 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote:
On 3/22/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
On Wed, 2006-03-22 at 12:14
--- Comment #9 from richard dot guenther at gmail dot com 2006-03-22 11:14
---
Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller
On 3/21/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
It turns out this specialized PHI optimization pass is as effective
as running
--- Comment #10 from law at redhat dot com 2006-03-22 14:01 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Wed, 2006-03-22 at 12:14 +0100, Richard Guenther wrote:
On 3/21/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
It turns out this specialized
--- Comment #11 from richard dot guenther at gmail dot com 2006-03-22
15:06 ---
Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller
On 3/22/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
On Wed, 2006-03-22 at 12:14 +0100, Richard Guenther wrote:
On 3/21/06, Jeffrey
--- Comment #12 from law at redhat dot com 2006-03-22 15:36 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote:
;
see tv_id - so I guess increased CCP times are expected.
Nuts. I should have
--- Comment #6 from law at redhat dot com 2006-03-21 05:09 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Sat, 2006-02-11 at 00:59 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-11
--- Comment #8 from law at redhat dot com 2006-03-21 05:10 ---
Today's patch picks up the missed const-propagation and allows
simplification of the modulo operation.
THere's still the opportunitity to use range information to simplify
a conditional. However, fixing that is just
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-11 00:59 ---
The problem with this one after Jeff's recent patches is that we have:
L13:;
D.1402_17 = 0;
if (D.1402_17 == 1) goto L15; else goto L14;
L15:;
x_18 = 1;
# x_19 = PHI 0(2), 0(3), x_18(4);
L14:;
Which
--- Comment #4 from law at redhat dot com 2006-02-09 03:19 ---
I'll note this really isn't a jump threading issue. This is a fundamental
weakness in a dominator based optimizer vs a truly global optimizer.
What we've got is a block which looks something like this:
# u_18 = PHI
11 matches
Mail list logo
