Questions about selective scheduler and PowerPC

[Jie Zhang <jie at codesourcery dot com>]

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  <edelsohn@gnu.org>

        * 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