This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Defining scheduling resource constraint


> -----Original Message-----
> From: Bernd Schmidt [mailto:bernds@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]