On Friday 25 March 2005 02:09, James E Wilson wrote:
I tried it, it doesn't help. It solves neither the loop invariant code
motion problem nor the do-loop optimization problem.
As pointed out by Andrew Pinski, the do-loop transformation was in fact
not valid. The rest of the slowdown looks
On Friday 25 March 2005 01:31, James E Wilson wrote:
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general,
Steve Ellcey wrote:
Any optimization experts care to take a look at this test case and help
me understand what is going on and if this change from 3.4 to 4.0 is
intentional or not?
Use the -da -fdump-tree-all options, and start looking at the dumps.
The first thing I notice is that in the RTL
On Thursday 24 March 2005 23:28, James E Wilson wrote:
I'd suggest filing a bug report for this problem to make sure it gets
fixed.
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general, yes, but we will probably always need some RTL loop
On Mar 24, 2005, at 7:31 PM, James E Wilson wrote:
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general, yes, but we
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote:
Jim you know that -fmove-loop-invariants enables the new RTL BB based
loop optimizer? This option was added back in 3.4.0.
No, I don't, and I stupidly didn't bother to check. I thought he was
talking about some tree-ssa option.
I tried it, it
On Mar 24, 2005, at 8:09 PM, James E Wilson wrote:
I tried it, it doesn't help. It solves neither the loop invariant code
motion problem nor the do-loop optimization problem.
The do-loop optimization which 3.3/3.4 was doing was invalid (see the
bug
referenced below).
I filed it under PR 19210
I have been looking at a significant performance regression in the hmmer
application between GCC 3.4 and GCC 4.0. I have a small cutdown test
case (attached) that demonstrates the problem and which runs more than
10% slower on IA64 (HP-UX or Linux) when compiled with GCC 4.0 than when
compiled
Steve Ellcey schrieb:
Test Case ---
I think is the same bug(which was not considered one back then) as
benjamin redelings described in the thread C++ math optimization
problem
there are again unnecessary memory accesses as if the memory were
10 matches
Mail list logo
