--- Comment #16 from sje at cup dot hp dot com 2006-06-08 15:50 ---
Bizarre, I could swear that when I first tried your fix I got a call to
__muldi3, but I just updated expmed.c, reran the test case and I got the same
inlined sequence that I got before the patch. I think in the first ca
--- Comment #15 from bonzini at gnu dot org 2006-06-08 15:40 ---
Subject: Bug 27733
Author: bonzini
Date: Thu Jun 8 15:40:48 2006
New Revision: 114488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114488
Log:
2006-06-08 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--- Comment #14 from bonzini at gnu dot org 2006-06-08 15:37 ---
Well, it shouldn't. My guess could be that we are hitting the case where the
logic is flawed. The we fill the cache with the algorithm for say 0x10085
(but then we only write 0x84 in the cache), and then use it for 0x
--- Comment #13 from sje at cup dot hp dot com 2006-06-08 15:11 ---
The proposed patch does fix the compilation time problem on hppa64-hp-hpux11.11
but I am confused about how the cache works. Without the patch, the compile
takes 15 to 20 minutes but I do wind up generating a sequence o
--- Comment #12 from bonzini at gnu dot org 2006-06-08 12:26 ---
Created an attachment (id=11634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view)
proposed patch
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from bonzini at gnu dot org 2006-06-08 12:24 ---
OUCH! The number is stored as a unsigned int in the cache, which means that
numbers > 2^32 never hit the cache!
Besides that, it's wise to enlarge the cache for 64-bit hosts, because there
every EXACT_DIV_EXPR will call sy
--- Comment #10 from bonzini at gnu dot org 2006-06-08 12:08 ---
Reduced testcase:
long foo(long zz)
{
return zz * 15238614669586151335;
}
takes "ridiculously long" with -O2 -mdisable-fpregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
--- Comment #9 from sje at cup dot hp dot com 2006-06-06 21:30 ---
3.39s is not ridiculously slow, 15+ minutes is ridiculously slow. 1.64 seconds
using the constant 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
--- Comment #8 from falk at debian dot org 2006-06-06 21:04 ---
(In reply to comment #7)
> PR 23971 is closed as fixed, I don't know if alpha is having this problem
> anymore or not.
It takes 3.39s now, which while much faster than it used to be is still
ridiculously slow (with 1 as co
--- Comment #7 from sje at cup dot hp dot com 2006-06-06 20:48 ---
This seems to be identical to PR 23971 on alpha. The test case for that PR:
unsigned long long f(unsigned long long x) { return x *
5445825408751490200ULL;}
I changed long to 'long long' to make it 64 bits on hppa1.1 a
--- Comment #6 from sje at cup dot hp dot com 2006-06-06 19:52 ---
Created an attachment (id=11612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11612&action=view)
Cut down test case
Here is a cutdown test case. I reproduced the problem on hppa64-hp-hpux11.11
with this cutdown t
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-25 02:35
---
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23
13:49 ---
Subject: Re: [4.1/4.2 Regression] Large compile time regression
> This is not the first time multiply expand is taking this long.
>
> There was another bug about something like this but for alpha.
Note t
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-23 02:29 ---
This is not the first time multiply expand is taking this long.
There was another bug about something like this but for alpha.
It would be interesting which multiply is getting messed up by expand.
--
pinskia a
15 matches
Mail list logo
