Adam Nemet wrote:
haifa-sched.c: 2302 /* Let the target filter the search space. */ 2303 for (i = 1; i < ready->n_ready; i++) 2304 if (!ready_try[i]) 2305 { 2306 insn = ready_element (ready, i); 2307 2308 gcc_assert (INSN_CODE (insn) >= 0 2309 || recog_memoized (insn) < 0);I am hitting this assert with the Octeon pipeline patch. Isn't the check on recog_memoized reversed? Or are we really asserting here that the insn has either been recognized earlier or won't be recognized now either?!
Yes, the assert is really checking exactly that. Several pieces of haifa-sched.c assume that the instruction has been recognized during scheduler initialization to speed up checking if instruction is normal or some kind of use/clobber/asm.
As max_issue () is one of hot spots in scheduler (and compiler), not calling recog_memoized() saves up some time.
If the assert is failing, then something is wrong at initialization stage. -- Maxim
