> -----Original Message----- > From: Bernd Schmidt [mailto:ber...@codesourcery.com] > Sent: 06 November 2012 17:12 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Defining scheduling resource constraint > > On 11/06/2012 05:50 PM, Paulo Matos wrote: > > > I am following your advice and using sched.reorg to remove the > > instruction from the ready list. What I am doing is checking the > > register written in ready[n_ready - 1] (if any) and look for the > > remainder of the ready list for insns writing to the same register. > > That probably won't work, you'll need to keep track of which registers > have already been written in the current cycle - that needs to be > updated in the variable_issue hook. >
I was assuming that ready[*n_readyp - 1] was the next scheduled insn and therefore I only needed to compare the register writes of all insns from ready[0] to ready[*n_readyp -2]. > > If I find one such insn, in index k, then I remove the insn by > > moving > all insns from 0 -> k-1 to 1-> k (essentially shifting right all > instructions below k. > > If you also put it back into the position in the array that has become > free, that sounds about right. > > > However this is getting me into trouble with an ice. I feel like I > should instead be moving the instruction from ready to pending instead > of simply removing it from ready, however I have no access to > Haifa-sched.c internals from the backend. > > Well, if you're doing it right, you're not really removing the > instructions, just reordering the array and returning a different value > for n_ready. Look at c6x.c for some example code. > Yes, the reordering works fine. The problem is when I change the value of *n_readyp. The c6x port returns n_ready (which for me doesn't make sense since the max insns I can schedule in a cycle is 2 which is my issue_rate), but doesn't change *n_readyp. If I don't change *n_readyp I am not actually 'removing' the insn from ready but simply reordering it. The docs say I can modify *n_readyp but any attempt to do so is causing an ice at schedule_block with instruction: gcc_assert(ready.n_ready) after the call to queue_to_ready(&ready); I will try to study haifa-sched.c to see what the problem is. -- Paulo Matos
