Re: Questions about selective scheduler and PowerPC
On 10/23/2010 01:50 AM, Pat Haugen wrote: On 10/20/2010 7:48 PM, Jie Zhang wrote: Running CPU2006, with the hack removed I see about a 1% improvement in specint (10% in 456.hmmer, a couple others in the 3% range, -3% 401.bzip2) and a 1% degradation in specfp (mainly due to a 13% degradation in 435.gromacs). But 454.calculix also fails for me (output miscompare), so assume we're generating incorrect code for some reason with the hack removed. Thanks for benchmarking! Since there is a bug in max_issue, issue_rate is not really honored. Could you try this patch http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01719.html with and without the hack? With your patch applied I see pretty similar results as before, except for a couple additional specint benchmarks that degraded a couple percent with the hack removed. Thanks for testing! Seems rs6000 port still has to keep that hack for now. -- Jie Zhang CodeSourcery
Re: Questions about selective scheduler and PowerPC
On 10/20/2010 7:48 PM, Jie Zhang wrote: Running CPU2006, with the hack removed I see about a 1% improvement in specint (10% in 456.hmmer, a couple others in the 3% range, -3% 401.bzip2) and a 1% degradation in specfp (mainly due to a 13% degradation in 435.gromacs). But 454.calculix also fails for me (output miscompare), so assume we're generating incorrect code for some reason with the hack removed. Thanks for benchmarking! Since there is a bug in max_issue, issue_rate is not really honored. Could you try this patch http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01719.html with and without the hack? With your patch applied I see pretty similar results as before, except for a couple additional specint benchmarks that degraded a couple percent with the hack removed. -Pat
Re: Questions about selective scheduler and PowerPC
On 10/21/2010 04:08 AM, Pat Haugen wrote: On 10/18/2010 10:33 AM, Jeff Law wrote: On 10/18/10 09:22, David Edelsohn wrote: On Mon, Oct 18, 2010 at 8:27 AM, Nathan Froyd wrote: On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: 3. The aforementioned rs6000 hack rs6000_issue_rate was added by 2003-03-03 David Edelsohn * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete. (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete. (rs6000_variable_issue): Do not return negative value. (rs6000_issue_rate): Uniformly set issue rate to 1 for first scheduling pass. , which was more than 7 years ago. Is this still needed now? I asked David about this on IRC several days ago. He indicated that it was necessary to prevent the first scheduling pass from unnecessarily increasing register pressure. I don't know whether anybody has actually tested it with recent GCC, though presumably it did help when it was installed. I am not sure when it last was re-checked, but it was checked after sched_pressure was added. When that option is not enabled, the issue_rate change still helped. Did anyone check this after Bernd's work to better handle allocation of double-word pseudos in IRA? That code should be handling the false conflicts created by movement of clobbers. Running CPU2006, with the hack removed I see about a 1% improvement in specint (10% in 456.hmmer, a couple others in the 3% range, -3% 401.bzip2) and a 1% degradation in specfp (mainly due to a 13% degradation in 435.gromacs). But 454.calculix also fails for me (output miscompare), so assume we're generating incorrect code for some reason with the hack removed. Thanks for benchmarking! Since there is a bug in max_issue, issue_rate is not really honored. Could you try this patch http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01719.html with and without the hack? Regards, -- Jie Zhang CodeSourcery
Re: Questions about selective scheduler and PowerPC
On 10/18/2010 10:33 AM, Jeff Law wrote: On 10/18/10 09:22, David Edelsohn wrote: On Mon, Oct 18, 2010 at 8:27 AM, Nathan Froyd wrote: On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: 3. The aforementioned rs6000 hack rs6000_issue_rate was added by 2003-03-03 David Edelsohn * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete. (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete. (rs6000_variable_issue): Do not return negative value. (rs6000_issue_rate): Uniformly set issue rate to 1 for first scheduling pass. , which was more than 7 years ago. Is this still needed now? I asked David about this on IRC several days ago. He indicated that it was necessary to prevent the first scheduling pass from unnecessarily increasing register pressure. I don't know whether anybody has actually tested it with recent GCC, though presumably it did help when it was installed. I am not sure when it last was re-checked, but it was checked after sched_pressure was added. When that option is not enabled, the issue_rate change still helped. Did anyone check this after Bernd's work to better handle allocation of double-word pseudos in IRA? That code should be handling the false conflicts created by movement of clobbers. Running CPU2006, with the hack removed I see about a 1% improvement in specint (10% in 456.hmmer, a couple others in the 3% range, -3% 401.bzip2) and a 1% degradation in specfp (mainly due to a 13% degradation in 435.gromacs). But 454.calculix also fails for me (output miscompare), so assume we're generating incorrect code for some reason with the hack removed. -Pat
Re: Questions about selective scheduler and PowerPC
> [quote] > Target Hook: int TARGET_SCHED_ISSUE_RATE (void) > [snip] > Although the insn scheduler can define itself the possibility of issue > an insn on the same cycle, the value can serve as an additional > constraint to issue insns on the same simulated processor cycle > [snip] > [/quote] > > it should be allowed to be defined smaller than the issue rate defined > by the scheduler DFA. So even if the backend defines a DFA which is > capable to issue 4 instructions in one cycle but it also defines > TARGET_SCHED_ISSUE_RATE to 3, the scheduler should restrict the number > of instructions issued in one cycle to 3 instead of 4. FWIW I have a strong suspicion that there are scheduler descriptions in the ARM backend that rely on TARGET_SCHED_ISSUE_RATE instead of explicitly modelling the issue unit. Paul
Re: Questions about selective scheduler and PowerPC
On 10/19/2010 10:16 PM, Andrey Belevantsev wrote:
On 19.10.2010 17:57, Jie Zhang wrote:
Removing the failing assert fixes the test case. But I wonder why not
just
get max_issue correct. I'm testing the attached patch. IMHO, max_issue
looks confusing.
* The concept of ISSUE POINT has never been used since the code landed in
repository.
* In the comment just before the function, it's mentioned that MAX_POINTS
is the sum of points of all instructions in READY. But it does not match
the code. The code only summarizes the points of the first MORE_ISSUE
instructions. If later ISSUE_POINTS become not uniform, that piece of
code
should be redesigned.
So I think it's good to remove it now. And "top - choice_stack" is a good
replacement for top->n. So we can remove field n from struct
choice_entry,
too.
Now I'm looking at MIPS target to find out why this change in the would
cause PR37360.
I agree that ISSUE_POINTS can be removed, as it was not used (maybe
Maxim can comment more on this). However, the assert is not about the
points but exactly about the situation when a target is lying to the
compiler about its issue rate.
The ideal situation is that we agree on that this should never happen,
but then you need to fix all targets that use this trick, and it seems
that there is at least mips, ppc, and x86-64 (which is why I pointed you
to 45352). The fix would be to find out why claiming the true issue rate
degrades performance and to implement the proper scheduling hooks for
changing priority of some insns, or to enable -fsched-pressure for the
offending targets.
I agree. But I still have a question about TARGET_SCHED_ISSUE_RATE.
According to my understanding of gccint:
[quote]
Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
[snip]
Although the insn scheduler can define itself the possibility of issue
an insn on the same cycle, the value can serve as an additional
constraint to issue insns on the same simulated processor cycle
[snip]
[/quote]
it should be allowed to be defined smaller than the issue rate defined
by the scheduler DFA. So even if the backend defines a DFA which is
capable to issue 4 instructions in one cycle but it also defines
TARGET_SCHED_ISSUE_RATE to 3, the scheduler should restrict the number
of instructions issued in one cycle to 3 instead of 4.
So I think this assert should hold even the backend lies to scheduler
about the issue rate. Fixing the lies is another problem.
With the attached draft patch, we can enable the assert in max_issue
without regression on PR37360.
This is a lot of work, which is why this assert was installed in
max_issue for relatively short amount of time. Maybe it's time to try
again, but let's have a consensus first that this assert should never
trigger by design and we have enough flexibility in the scheduler to
provide legal means to achieve the same performance effect.
Agree.
Regards,
--
Jie Zhang
CodeSourcery
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index b13d648..7653941 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -589,6 +589,10 @@ static const char *mips_hi_relocs[NUM_SYMBOL_TYPES];
/* Target state for MIPS16. */
struct target_globals *mips16_globals;
+/* Cached value of can_issue_more. This is cached in mips_variable_issue hook
+ and returned from mips_sched_reorder2. */
+static int cached_can_issue_more;
+
/* Index R is the smallest register class that contains register R. */
const enum reg_class mips_regno_to_class[FIRST_PSEUDO_REGISTER] = {
LEA_REGS, LEA_REGS, M16_REGS, V1_REG,
@@ -12439,8 +12443,8 @@ mips_sched_init (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
/* Implement TARGET_SCHED_REORDER and TARGET_SCHED_REORDER2. */
static int
-mips_sched_reorder (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
- rtx *ready, int *nreadyp, int cycle ATTRIBUTE_UNUSED)
+mips_sched_reorder_1 (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
+ rtx *ready, int *nreadyp, int cycle ATTRIBUTE_UNUSED)
{
if (!reload_completed
&& TUNE_MACC_CHAINS
@@ -12455,10 +12459,25 @@ mips_sched_reorder (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
if (TUNE_74K)
mips_74k_agen_reorder (ready, *nreadyp);
+}
+
+static int
+mips_sched_reorder (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
+ rtx *ready, int *nreadyp, int cycle ATTRIBUTE_UNUSED)
+{
+ mips_sched_reorder_1 (file, verbose, ready, nreadyp, cycle);
return mips_issue_rate ();
}
+static int
+mips_sched_reorder2 (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
+ rtx *ready, int *nreadyp, int cycle ATTRIBUTE_UNUSED)
+{
+ mips_sched_reorder_1 (file, verbose, ready, nreadyp, cycle);
+ return cached_can_issue_more;
+}
+
/* Update round-robin counters for ALU1/2 and FALU1/2. */
static void
@@ -12516,6 +12535,7 @@ mips_variable_issue (FILE *file ATTRIBUTE_UNUSED, int verbose ATTRIBUTE_UNUSED,
|| recog_memoized (ins
Re: Questions about selective scheduler and PowerPC
On 10/19/10 6:16 PM, Andrey Belevantsev wrote: ... I agree that ISSUE_POINTS can be removed, as it was not used (maybe Maxim can comment more on this). I too agree with removing ISSUE_POINTS, it never found any use. Regards, -- Maxim Kuvyrkov CodeSourcery ma...@codesourcery.com (650) 331-3385 x724
Re: Questions about selective scheduler and PowerPC
On 19.10.2010 17:57, Jie Zhang wrote: Removing the failing assert fixes the test case. But I wonder why not just get max_issue correct. I'm testing the attached patch. IMHO, max_issue looks confusing. * The concept of ISSUE POINT has never been used since the code landed in repository. * In the comment just before the function, it's mentioned that MAX_POINTS is the sum of points of all instructions in READY. But it does not match the code. The code only summarizes the points of the first MORE_ISSUE instructions. If later ISSUE_POINTS become not uniform, that piece of code should be redesigned. So I think it's good to remove it now. And "top - choice_stack" is a good replacement for top->n. So we can remove field n from struct choice_entry, too. Now I'm looking at MIPS target to find out why this change in the would cause PR37360. I agree that ISSUE_POINTS can be removed, as it was not used (maybe Maxim can comment more on this). However, the assert is not about the points but exactly about the situation when a target is lying to the compiler about its issue rate. The ideal situation is that we agree on that this should never happen, but then you need to fix all targets that use this trick, and it seems that there is at least mips, ppc, and x86-64 (which is why I pointed you to 45352). The fix would be to find out why claiming the true issue rate degrades performance and to implement the proper scheduling hooks for changing priority of some insns, or to enable -fsched-pressure for the offending targets. This is a lot of work, which is why this assert was installed in max_issue for relatively short amount of time. Maybe it's time to try again, but let's have a consensus first that this assert should never trigger by design and we have enough flexibility in the scheduler to provide legal means to achieve the same performance effect. Andrey /* ??? 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); */ + be disabled. */
Re: Questions about selective scheduler and PowerPC
On 10/18/2010 03:41 PM, Andrey Belevantsev wrote:
On 18.10.2010 11:31, Jie Zhang wrote:
Hi Andrey,
On 10/18/2010 03:13 PM, Andrey Belevantsev wrote:
Hi Jie,
On 18.10.2010 10:49, Jie Zhang wrote:
When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and
issue_rate is
1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but
rs6000_issue_rate lies to scheduler that it can only issue 1
instruction
before register relocation is done. See the following code:
See PR 45352. I've tried to fix this in the selective scheduler by
modeling the lying behavior in line with the haifa scheduler. Let me
know if the last patch from the PR audit trail doesn't work for you.
In addition, after the above patch goes in, I can make the selective
scheduler not try to jump through the hoops with putting correct sched
cycles on insns for targets which don't need it in their target_finish
hook. I guess powerpc needs this though, but x86-64 (for which PR 45342
was opened) almost surely does not.
Thanks for your reply. I just tried. That patch does not help for this
issue.
I see, I didn't touch the failing assert with the patch. Can you just
remove the assert and see if that helps for you? I cannot think of how
it can be relaxed and still be useful.
Removing the failing assert fixes the test case. But I wonder why not
just get max_issue correct. I'm testing the attached patch. IMHO,
max_issue looks confusing.
* The concept of ISSUE POINT has never been used since the code landed
in repository.
* In the comment just before the function, it's mentioned that
MAX_POINTS is the sum of points of all instructions in READY. But it
does not match the code. The code only summarizes the points of the
first MORE_ISSUE instructions. If later ISSUE_POINTS become not uniform,
that piece of code should be redesigned.
So I think it's good to remove it now. And "top - choice_stack" is a
good replacement for top->n. So we can remove field n from struct
choice_entry, too.
Now I'm looking at MIPS target to find out why this change in the would
cause PR37360.
/* ??? 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); */
+ be disabled. */
--
Jie Zhang
CodeSourcery
* haifa-sched.c (ISSUE_POINTS): Remove.
(struct choice_entry): Remove field n.
(max_issue): Don't issue more than issue_rate instructions.
Index: haifa-sched.c
===
--- haifa-sched.c (revision 165642)
+++ haifa-sched.c (working copy)
@@ -199,10 +199,6 @@ struct common_sched_info_def *common_sch
/* The minimal value of the INSN_TICK of an instruction. */
#define MIN_TICK (-max_insn_queue_index)
-/* Issue points are used to distinguish between instructions in max_issue ().
- For now, all instructions are equally good. */
-#define ISSUE_POINTS(INSN) 1
-
/* List of important notes we must keep around. This is a pointer to the
last element in the list. */
rtx note_list;
@@ -2401,8 +2397,6 @@ struct choice_entry
int index;
/* The number of the rest insns whose issues we should try. */
int rest;
- /* The number of issued essential insns. */
- int n;
/* State after issuing the insn. */
state_t state;
};
@@ -2444,8 +2438,7 @@ static int cached_issue_rate = 0;
insns is insns with the best rank (the first insn in READY). To
make this function tries different samples of ready insns. READY
is current queue `ready'. Global array READY_TRY reflects what
- insns are already issued in this try. MAX_POINTS is the sum of points
- of all instructions in READY. The function stops immediately,
+ insns are already issued in this try. The function stops immediately,
if it reached the such a solution, that all instruction can be issued.
INDEX will contain index of the best insn in READY. The following
function is used only for first cycle multipass scheduling.
@@ -2458,7 +2451,7 @@ int
max_issue (struct ready_list *ready, int privileged_n, state_t state,
int *index)
{
- int n, i, all, n_ready, best, delay, tries_num, max_points;
+ int i, all, n_ready, best, delay, tries_num;
int more_issue;
struct choice_entry *top;
rtx insn;
@@ -2477,25 +2470,15 @@ max_issue (struct ready_list *ready, int
}
/* 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 a
Re: Questions about selective scheduler and PowerPC
On 10/18/10 09:22, David Edelsohn wrote: On Mon, Oct 18, 2010 at 8:27 AM, Nathan Froyd wrote: On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: 3. The aforementioned rs6000 hack rs6000_issue_rate was added by 2003-03-03 David Edelsohn * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete. (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete. (rs6000_variable_issue): Do not return negative value. (rs6000_issue_rate): Uniformly set issue rate to 1 for first scheduling pass. , which was more than 7 years ago. Is this still needed now? I asked David about this on IRC several days ago. He indicated that it was necessary to prevent the first scheduling pass from unnecessarily increasing register pressure. I don't know whether anybody has actually tested it with recent GCC, though presumably it did help when it was installed. I am not sure when it last was re-checked, but it was checked after sched_pressure was added. When that option is not enabled, the issue_rate change still helped. Did anyone check this after Bernd's work to better handle allocation of double-word pseudos in IRA? That code should be handling the false conflicts created by movement of clobbers. jeff
Re: Questions about selective scheduler and PowerPC
On Mon, Oct 18, 2010 at 8:27 AM, Nathan Froyd wrote: > On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: >> 3. The aforementioned rs6000 hack rs6000_issue_rate was added by >> >> 2003-03-03 David Edelsohn >> >> * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete. >> (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete. >> (rs6000_variable_issue): Do not return negative value. >> (rs6000_issue_rate): Uniformly set issue rate to 1 for first >> scheduling pass. >> >> , which was more than 7 years ago. Is this still needed now? > > I asked David about this on IRC several days ago. He indicated that it > was necessary to prevent the first scheduling pass from unnecessarily > increasing register pressure. I don't know whether anybody has actually > tested it with recent GCC, though presumably it did help when it was > installed. I am not sure when it last was re-checked, but it was checked after sched_pressure was added. When that option is not enabled, the issue_rate change still helped. - David
Re: Questions about selective scheduler and PowerPC
On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: > 3. The aforementioned rs6000 hack rs6000_issue_rate was added by > > 2003-03-03 David Edelsohn > > * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete. > (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete. > (rs6000_variable_issue): Do not return negative value. > (rs6000_issue_rate): Uniformly set issue rate to 1 for first > scheduling pass. > > , which was more than 7 years ago. Is this still needed now? I asked David about this on IRC several days ago. He indicated that it was necessary to prevent the first scheduling pass from unnecessarily increasing register pressure. I don't know whether anybody has actually tested it with recent GCC, though presumably it did help when it was installed. -Nathan
Re: Questions about selective scheduler and PowerPC
On 18.10.2010 11:31, Jie Zhang wrote: Hi Andrey, On 10/18/2010 03:13 PM, Andrey Belevantsev wrote: Hi Jie, On 18.10.2010 10:49, Jie Zhang wrote: When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate is 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but rs6000_issue_rate lies to scheduler that it can only issue 1 instruction before register relocation is done. See the following code: See PR 45352. I've tried to fix this in the selective scheduler by modeling the lying behavior in line with the haifa scheduler. Let me know if the last patch from the PR audit trail doesn't work for you. In addition, after the above patch goes in, I can make the selective scheduler not try to jump through the hoops with putting correct sched cycles on insns for targets which don't need it in their target_finish hook. I guess powerpc needs this though, but x86-64 (for which PR 45342 was opened) almost surely does not. Thanks for your reply. I just tried. That patch does not help for this issue. I see, I didn't touch the failing assert with the patch. Can you just remove the assert and see if that helps for you? I cannot think of how it can be relaxed and still be useful. Andrey
Re: Questions about selective scheduler and PowerPC
Hi Andrey, On 10/18/2010 03:13 PM, Andrey Belevantsev wrote: Hi Jie, On 18.10.2010 10:49, Jie Zhang wrote: When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate is 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but rs6000_issue_rate lies to scheduler that it can only issue 1 instruction before register relocation is done. See the following code: See PR 45352. I've tried to fix this in the selective scheduler by modeling the lying behavior in line with the haifa scheduler. Let me know if the last patch from the PR audit trail doesn't work for you. In addition, after the above patch goes in, I can make the selective scheduler not try to jump through the hoops with putting correct sched cycles on insns for targets which don't need it in their target_finish hook. I guess powerpc needs this though, but x86-64 (for which PR 45342 was opened) almost surely does not. Thanks for your reply. I just tried. That patch does not help for this issue. -- Jie Zhang CodeSourcery
Re: Questions about selective scheduler and PowerPC
Hi Jie, On 18.10.2010 10:49, Jie Zhang wrote: When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate is 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but rs6000_issue_rate lies to scheduler that it can only issue 1 instruction before register relocation is done. See the following code: See PR 45352. I've tried to fix this in the selective scheduler by modeling the lying behavior in line with the haifa scheduler. Let me know if the last patch from the PR audit trail doesn't work for you. In addition, after the above patch goes in, I can make the selective scheduler not try to jump through the hoops with putting correct sched cycles on insns for targets which don't need it in their target_finish hook. I guess powerpc needs this though, but x86-64 (for which PR 45342 was opened) almost surely does not. Thanks, Andrey
Questions about selective scheduler and PowerPC
Hi,
I'm investigating a GCC testsuite FAIL of PowerPC with e500 multilib.
The test is pr42245.c, which sets options to "-O2 -fselective-scheduling
-fsel-sched-pipelining".
$ ./cc1 -quiet pr42245.c -mcpu=8540 -mfloat-gprs=single -O2
-fselective-scheduling
pr42245.c: In function ‘build_DIS_CON_tree’:
pr42245.c:29:1: internal compiler error: in advance_state_on_fence, at
sel-sched.c:5288
The code around sel-sched.c:5288 looks like:
5265 static bool
5266 advance_state_on_fence (fence_t fence, insn_t insn)
5267 {
5268 bool asm_p;
5269
5270 if (recog_memoized (insn) >= 0)
5271 {
5272 int res;
5273 state_t temp_state = alloca (dfa_state_size);
5274
5275 gcc_assert (!INSN_ASM_P (insn));
5276 asm_p = false;
5277
5278 memcpy (temp_state, FENCE_STATE (fence), dfa_state_size);
5279 res = state_transition (FENCE_STATE (fence), insn);
5280 gcc_assert (res < 0);
5281
5282 if (memcmp (temp_state, FENCE_STATE (fence), dfa_state_size))
5283 {
5284 FENCE_ISSUED_INSNS (fence)++;
5285
5286 /* We should never issue more than issue_rate insns. */
5287 if (FENCE_ISSUED_INSNS (fence) > issue_rate)
5288 gcc_unreachable ();
5289 }
5290 }
5291 else
When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and issue_rate
is 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but
rs6000_issue_rate lies to scheduler that it can only issue 1 instruction
before register relocation is done. See the following code:
23205 static int
23206 rs6000_issue_rate (void)
23207 {
23208 /* Unless scheduling for register pressure, use issue rate of 1 for
23209 first scheduling pass to decrease degradation. */
23210 if (!reload_completed && !flag_sched_pressure)
23211 return 1;
23212
23213 switch (rs6000_cpu_attr) {
[snip]
23223 case CPU_PPC8540:
[snip]
23230 return 2;
This issue could be traced down to haifa-sched.c:max_issue (), which
returns 2 even issue_rate is 1. So my questions and possible ways to fix
it are:
1. Should we restrict max_issue to only return value less than or equal
to issue_rate?
2. Should we do the same as what SMS does? See
static void
sms_schedule (void)
{
[snip]
/* Initialize issue_rate. */
if (targetm.sched.issue_rate)
{
int temp = reload_completed;
reload_completed = 1;
issue_rate = targetm.sched.issue_rate ();
reload_completed = temp;
}
else
issue_rate = 1;
[snip]
}
I suspect this piece code in sms_schedule was written for rs6000, but it
comes as the first commit of SMS merge and there is no patch email
explaining it.
3. The aforementioned rs6000 hack rs6000_issue_rate was added by
2003-03-03 David Edelsohn
* config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.
(TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD): Delete.
(rs6000_variable_issue): Do not return negative value.
(rs6000_issue_rate): Uniformly set issue rate to 1 for first
scheduling pass.
, which was more than 7 years ago. Is this still needed now?
Any one of the above three ways can fix the FAIL. But I'm not sure which
way is best, or maybe we should do 1 and 3 and remove the hack in 2?
Thoughts?
Regards,
--
Jie Zhang
CodeSourcery
