[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 synth_mult with a very large multiplier. Time for a -O0 compiler on the reduced testcase is down to 0.3s for 2069 cache entries, and 0.8s for 1031 cache entries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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=11634action=view) proposed patch -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 of instructions instead of a call to __divdi3. With the patch, I get a very fast compilation, but I also get a call to __divdi3 instead of the code sequence. Why does caching results change the behaviour? Caches (in general) should speed things up by saving previous/intermediate results, but shouldn't change the ultimate answer. This seems to be doing something different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 0x85. The synth_mult logic then could be resilient enough to not generate wrong code but just code with wrong cost measures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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=gccview=revrev=114488 Log: 2006-06-08 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/27733 * expmed.c (struct alg_hash_entry): Fix type of field T to match synth_mult argument. (NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 case I had reduced the cost of MULT on hppa64 and that is why I got the __divdi3 call. I put the MULT cost back to where it was and now I get the inline sequence. In short, the compilation now takes 30 seconds instead of 15 minutes and I get the same code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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=11612action=view) Cut down test case Here is a cutdown test case. I reproduced the problem on hppa64-hp-hpux11.11 with this cutdown testcase. When compiling with -O2 it compiles quickly (less than 1 second) when compiled with -O2 -mdisable-fpregs it took 17 minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 and hppa64. It
compiles fine on hppa1.1-*-* but takes forever on hppa64-*-* with -O2
-mdisable-fpregs.
PR 23971 is closed as fixed, I don't know if alpha is having this problem
anymore or not.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-06 20:48:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 constant, it takes 0.06s). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 Target Milestone|4.1.1 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 that this is for a 32 to 64-bit hppa cross. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- 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 at gcc dot gnu dot org changed: What|Removed |Added Summary|Large compile time |[4.1/4.2 Regression] Large |regression |compile time regression Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
