This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
- From: "abel at ispras dot ru" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Sep 2008 07:19:19 -0000
- Subject: [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
- References: <bug-37360-7151@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #17 from abel at ispras dot ru 2008-09-08 07:19 -------
(In reply to comment #16)
> Could you explain why max_issue() should do anything
> when more_issue <= 0? I'd have expected it to early-out.
But the whole point of the patch is that we _can_ actually issue more insns
even when more_issue <= 0, because the backend is claiming lower issue_rate
than can be achieved (see comment #11). We can return 0 from max_issue when
more_issue <= 0, but I don't see offhand how the theoretical value of 4 issued
insns can then be achieved for sb1.
Actually, I have skimmed through *_issue_rate functions on other targets, and
it seems that only m32r has the same sort of comment for its issue_rate hook,
but by default the hook passes correct value. So I would be happy to do
whatever seems beneficial to mips/m32r maintainers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360