* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
@ 2008-09-04 0:43 ` pinskia at gcc dot gnu dot org
2008-09-04 9:46 ` rguenth at gcc dot gnu dot org
` (19 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-09-04 0:43 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Component|target |rtl-optimization
Summary|ICE in haifa-sched.c when |[4.4 Regression] ICE in
|compiling __popcountsi2 from|haifa-sched.c when compiling
|libgcc |__popcountsi2 from libgcc
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
2008-09-04 0:43 ` [Bug rtl-optimization/37360] [4.4 Regression] " pinskia at gcc dot gnu dot org
@ 2008-09-04 9:46 ` rguenth at gcc dot gnu dot org
2008-09-04 12:08 ` abel at ispras dot ru
` (18 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-09-04 9:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-04 09:44 -------
Andrey, this is likely due to the selective scheduler merge. Can you
investigate or delegate?
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
2008-09-04 0:43 ` [Bug rtl-optimization/37360] [4.4 Regression] " pinskia at gcc dot gnu dot org
2008-09-04 9:46 ` rguenth at gcc dot gnu dot org
@ 2008-09-04 12:08 ` abel at ispras dot ru
2008-09-04 14:36 ` abel at ispras dot ru
` (17 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-04 12:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from abel at ispras dot ru 2008-09-04 12:06 -------
> Andrey, this is likely due to the selective scheduler merge. Can you
> investigate or delegate?
We couldn't reproduce this with a cross from x86_64. Also, Adam Nemet fixed
the problem with MIPS/sel-sched bootstrap
(http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00152.html) -- the mail mentions
that he reached stage3 with his patch of 139918, this bug is of 139940. Can
this be reproduced natively on MIPS with 139918?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (2 preceding siblings ...)
2008-09-04 12:08 ` abel at ispras dot ru
@ 2008-09-04 14:36 ` abel at ispras dot ru
2008-09-04 14:50 ` daney at gcc dot gnu dot org
` (16 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-04 14:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from abel at ispras dot ru 2008-09-04 14:34 -------
This does not fail on a cross for us with 139918.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (3 preceding siblings ...)
2008-09-04 14:36 ` abel at ispras dot ru
@ 2008-09-04 14:50 ` daney at gcc dot gnu dot org
2008-09-04 14:59 ` hjl dot tools at gmail dot com
` (15 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-04 14:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from daney at gcc dot gnu dot org 2008-09-04 14:49 -------
You will note that I configured with --with-arch=sb1.
This in turn causes cc1 to be invoked with -march=sb1
I will attempt to test with a cross build.
My bootstrap gcc is: gcc (GCC) 4.4.0 20080223 (experimental) [trunk revision
132568]
There is the possibility that the stage1 compiler is being miscompiled, so I
will try another bootstrap with: gcc (Debian 4.3.1-8) 4.3.1 to see if that
changes anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (4 preceding siblings ...)
2008-09-04 14:50 ` daney at gcc dot gnu dot org
@ 2008-09-04 14:59 ` hjl dot tools at gmail dot com
2008-09-04 16:13 ` daney at gcc dot gnu dot org
` (14 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: hjl dot tools at gmail dot com @ 2008-09-04 14:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from hjl dot tools at gmail dot com 2008-09-04 14:58 -------
I would suggest to try ira-merge branch to rule out any IRA related
problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (5 preceding siblings ...)
2008-09-04 14:59 ` hjl dot tools at gmail dot com
@ 2008-09-04 16:13 ` daney at gcc dot gnu dot org
2008-09-04 17:19 ` daney at gcc dot gnu dot org
` (13 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-04 16:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from daney at gcc dot gnu dot org 2008-09-04 16:12 -------
I get the same ICE using gcc (Debian 4.3.1-8) 4.3.1 as the bootstrap compiler,
so I am going with the theory that the bootstrap compiler is not the cause of
this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (6 preceding siblings ...)
2008-09-04 16:13 ` daney at gcc dot gnu dot org
@ 2008-09-04 17:19 ` daney at gcc dot gnu dot org
2008-09-04 17:40 ` daney at gcc dot gnu dot org
` (12 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-04 17:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from daney at gcc dot gnu dot org 2008-09-04 17:17 -------
The problem is present in 139918
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (7 preceding siblings ...)
2008-09-04 17:19 ` daney at gcc dot gnu dot org
@ 2008-09-04 17:40 ` daney at gcc dot gnu dot org
2008-09-04 22:49 ` daney at gcc dot gnu dot org
` (11 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-04 17:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from daney at gcc dot gnu dot org 2008-09-04 17:39 -------
It is reproducible in a cross compiler as well.
This is my command line:
/home/daney/gccsvn/mipsel-trunk/gcc/cc1 -fpreprocessed j.i -quiet -march=sb1
-O2 -o j.s
Changing to -march={mips32,mips32r2,r5000} "fixes" the problem. It seems to be
sb1 specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (8 preceding siblings ...)
2008-09-04 17:40 ` daney at gcc dot gnu dot org
@ 2008-09-04 22:49 ` daney at gcc dot gnu dot org
2008-09-05 2:22 ` hjl dot tools at gmail dot com
` (10 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-04 22:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from daney at gcc dot gnu dot org 2008-09-04 22:48 -------
(In reply to comment #2)
> > Andrey, this is likely due to the selective scheduler merge. Can you
> > investigate or delegate?
> We couldn't reproduce this with a cross from x86_64. Also, Adam Nemet fixed
> the problem with MIPS/sel-sched bootstrap
> (http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00152.html) -- the mail mentions
> that he reached stage3 with his patch of 139918, this bug is of 139940. Can
> this be reproduced natively on MIPS with 139918?
>
The ICE first appears in 139854 (the sel-sched merge) it is still present in
139940 (and about 10 other version I tested between the two including 139918).
It is easily reproducible in a cross compile, but you must specify -march=sb1
to trigger it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (9 preceding siblings ...)
2008-09-04 22:49 ` daney at gcc dot gnu dot org
@ 2008-09-05 2:22 ` hjl dot tools at gmail dot com
2008-09-05 9:17 ` abel at ispras dot ru
` (9 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: hjl dot tools at gmail dot com @ 2008-09-05 2:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from hjl dot tools at gmail dot com 2008-09-05 02:21 -------
This may be related to PR 37378 and PR 37377.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (10 preceding siblings ...)
2008-09-05 2:22 ` hjl dot tools at gmail dot com
@ 2008-09-05 9:17 ` abel at ispras dot ru
2008-09-05 9:38 ` rguenth at gcc dot gnu dot org
` (8 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-05 9:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from abel at ispras dot ru 2008-09-05 09:16 -------
I was unable to trigger the assert on the given testcase even with the
cross-compiler configured exactly like the one in the bug report. However, I
was able to reproduce the ICE on a longer plain C test case.
The assert that triggers actually means that we will never issue more insns on
a cycle than issue_rate, i.e. cycle_issued_insns is always <= issue_rate.
However, both before and after selective scheduling merge, I see (the log is
given for the trunk just before sel-sched merge):
;; Ready list (t = 0): 117 101 100
;; Choosed insn : 100; points: 3/3
;; 0--> 100 $2=sxn([$18]) :sb1_ls0|sb1_ls1
;; dependencies resolved: insn 104
;; Ready-->Q: insn 104: queued for 1 cycles.
;; tick updated: insn 104 into queue with cost=1
;; dependencies resolved: insn 118
;; tick updated: insn 118 into ready
;; Ready list (t = 0): 118 117 101
;; Choosed insn : 101; points: 3/2
;; 0--> 101 $16=sxn([$17]) :sb1_ls0|sb1_ls1
;; dependencies resolved: insn 119
;; tick updated: insn 119 into ready
;; Ready list (t = 0): 119 118 117
;; Choosed insn : 117; points: 2/1
;; 0--> 117 $19=$19+0x1 :sb1_ls1|sb1_ex1|sb1_ex0
;; Ready list (t = 0): 119 118
;; Choosed insn : 118; points: 1/1
;; 0--> 118 $18=$18+0x1 :sb1_ls1|sb1_ex1|sb1_ex0
;; Ready list (t = 0): 119
;; Choosed insn : 119; points: -1/1
<assert is triggered here after the merge>
;; Ready-->Q: insn 119: queued for 1 cycles.
This means that we've issued insns 100, 101, 117, and 118, while at the same
time claiming that issue_rate is 3. In mips_issue_rate, I see the following:
case PROCESSOR_SB1:
case PROCESSOR_SB1A:
/* This is actually 4, but we get better performance if we claim 3.
This is partly because of unwanted speculative code motion with the
larger number, and partly because in most common cases we can't
reach the theoretical max of 4. */
return 3;
So this is while the assert is triggered only for those arches.
The assert was introduced with sel-sched merge just for purposes of stricter
checking. I was not aware of targets that claim issue rate which is lower than
the maximal value that can be actually achieved. I see that it is done on
purpose, however hackish it may seem though. So I'd propose to remove the
assert in max_issue and add a comment saying that for some targets the assert
may not be true. If people are happy with this, I will prepare a patch.
The other solution will be to fix mips.c to make it not to lie to the scheduler
about its issue rate, and fix the performance issues with e.g. lowering
priority of speculative motions in the appropriate scheduler hooks. But I
believe that this is not appropriate for stage3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (11 preceding siblings ...)
2008-09-05 9:17 ` abel at ispras dot ru
@ 2008-09-05 9:38 ` rguenth at gcc dot gnu dot org
2008-09-05 10:33 ` abel at ispras dot ru
` (7 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-09-05 9:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-05 09:37 -------
I think it's reasonable to disable the assert with a comment for now and
file a separate bugreport for the targets who lie about their issue rate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (12 preceding siblings ...)
2008-09-05 9:38 ` rguenth at gcc dot gnu dot org
@ 2008-09-05 10:33 ` abel at ispras dot ru
2008-09-05 10:35 ` abel at ispras dot ru
` (6 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-05 10:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from abel at ispras dot ru 2008-09-05 10:32 -------
(In reply to comment #12)
> I think it's reasonable to disable the assert with a comment for now and
> file a separate bugreport for the targets who lie about their issue rate.
Ok, with the below patch my failing test case compiles in an identical assembly
as it was compiled before the sel-sched merge. I've also bootstrapped it on
x86_64. If the patch will fix MIPS bootstrap, I think it can be committed as
obvious.
2008-09-05 Andrey Belevantsev <abel@ispras.ru>
PR 37360
* haifa-sched.c (max_issue): Do not assert that we never issue more
insns than issue_rate.
Add comment.
Index: gcc/haifa-sched.c
===================================================================
*** gcc/haifa-sched.c (revision 140031)
--- gcc/haifa-sched.c (working copy)
*************** max_issue (struct ready_list *ready, int
*** 2071,2077 ****
/* Init max_points. */
max_points = 0;
more_issue = issue_rate - cycle_issued_insns;
! gcc_assert (more_issue >= 0);
for (i = 0; i < n_ready; i++)
if (!ready_try [i])
--- 2071,2084 ----
/* Init max_points. */
max_points = 0;
more_issue = issue_rate - cycle_issued_insns;
!
! /* ??? We used to assert here that we never issue more insns than
issue_rate.
! However, some targets (e.g. MIPS/SB1) claim lower issue rate than can be
! achieved to get better performance. Until these targets are fixed to
use
! scheduler hooks to manipulate insns priority instead, the assert should
! be disabled.
!
! gcc_assert (more_issue >= 0); */
for (i = 0; i < n_ready; i++)
if (!ready_try [i])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (13 preceding siblings ...)
2008-09-05 10:33 ` abel at ispras dot ru
@ 2008-09-05 10:35 ` abel at ispras dot ru
2008-09-05 18:31 ` daney at gcc dot gnu dot org
` (5 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-05 10:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from abel at ispras dot ru 2008-09-05 10:33 -------
Created an attachment (id=16231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16231&action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (14 preceding siblings ...)
2008-09-05 10:35 ` abel at ispras dot ru
@ 2008-09-05 18:31 ` daney at gcc dot gnu dot org
2008-09-06 11:24 ` rsandifo at gcc dot gnu dot org
` (4 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: daney at gcc dot gnu dot org @ 2008-09-05 18:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from daney at gcc dot gnu dot org 2008-09-05 18:29 -------
Thanks for the patch.
With the patch applied to the trunk my bootstrap has made it into stage 2,
indicating that it has corrected the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (15 preceding siblings ...)
2008-09-05 18:31 ` daney at gcc dot gnu dot org
@ 2008-09-06 11:24 ` rsandifo at gcc dot gnu dot org
2008-09-08 7:20 ` abel at ispras dot ru
` (3 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: rsandifo at gcc dot gnu dot org @ 2008-09-06 11:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from rsandifo at gcc dot gnu dot org 2008-09-06 11:23 -------
Could you explain why max_issue() should do anything
when more_issue <= 0? I'd have expected it to early-out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (16 preceding siblings ...)
2008-09-06 11:24 ` rsandifo at gcc dot gnu dot org
@ 2008-09-08 7:20 ` abel at ispras dot ru
2008-09-09 12:57 ` abel at gcc dot gnu dot org
` (2 subsequent siblings)
20 siblings, 0 replies; 26+ messages in thread
From: abel at ispras dot ru @ 2008-09-08 7:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (17 preceding siblings ...)
2008-09-08 7:20 ` abel at ispras dot ru
@ 2008-09-09 12:57 ` abel at gcc dot gnu dot org
2008-09-09 14:22 ` abel at gcc dot gnu dot org
2008-09-09 14:37 ` abel at gcc dot gnu dot org
20 siblings, 0 replies; 26+ messages in thread
From: abel at gcc dot gnu dot org @ 2008-09-09 12:57 UTC (permalink / raw)
To: gcc-bugs
--
abel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|abel at ispras dot ru |abel at gcc dot gnu dot org
AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-09-09 12:56:38
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (18 preceding siblings ...)
2008-09-09 12:57 ` abel at gcc dot gnu dot org
@ 2008-09-09 14:22 ` abel at gcc dot gnu dot org
2008-09-09 14:37 ` abel at gcc dot gnu dot org
20 siblings, 0 replies; 26+ messages in thread
From: abel at gcc dot gnu dot org @ 2008-09-09 14:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from abel at gcc dot gnu dot org 2008-09-09 14:21 -------
Subject: Bug 37360
Author: abel
Date: Tue Sep 9 14:19:31 2008
New Revision: 140151
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140151
Log:
PR rtl-optimization/37360
* haifa-sched.c (max_issue): Do not assert that we never issue more
insns than issue_rate. Add comment.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread* [Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
2008-09-04 0:37 [Bug target/37360] New: ICE in haifa-sched.c when compiling __popcountsi2 from libgcc daney at gcc dot gnu dot org
` (19 preceding siblings ...)
2008-09-09 14:22 ` abel at gcc dot gnu dot org
@ 2008-09-09 14:37 ` abel at gcc dot gnu dot org
20 siblings, 0 replies; 26+ messages in thread
From: abel at gcc dot gnu dot org @ 2008-09-09 14:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from abel at gcc dot gnu dot org 2008-09-09 14:35 -------
Fixed in 140151.
--
abel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
^ permalink raw reply [flat|nested] 26+ messages in thread