RE: Defining scheduling resource constraint
-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
Re: Defining scheduling resource constraint
On 11/07/2012 11:41 AM, Paulo Matos wrote: 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. Look at the caller of the hook - they check the return value to see if any more instructions can be issued. If yes, the one highest on the list is picked. 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); Yes... I seem to remember the documentation is just wrong for that hook (and the interface is somewhat broken). As you noted, you can't just remove insns from the ready list without moving them somewhere else. Bernd
RE: Defining scheduling resource constraint
-Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 07 November 2012 10:48 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Yes... I seem to remember the documentation is just wrong for that hook (and the interface is somewhat broken). As you noted, you can't just remove insns from the ready list without moving them somewhere else. But if I can't remove an insn from the ready list (by 'remove' I mean reorder such that gcc understands that the insn should be postponed to the next cycle) in the reorder hook, I will give the adjust priorities hook a try and maybe here I can ensure that two insns that write to the same registers do not have the same priority. -- Paulo Matos
Re: Defining scheduling resource constraint
On 11/07/2012 12:08 PM, Paulo Matos wrote: -Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 07 November 2012 10:48 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Yes... I seem to remember the documentation is just wrong for that hook (and the interface is somewhat broken). As you noted, you can't just remove insns from the ready list without moving them somewhere else. But if I can't remove an insn from the ready list (by 'remove' I mean reorder such that gcc understands that the insn should be postponed to the next cycle) in the reorder hook, I will give the adjust priorities hook a try and maybe here I can ensure that two insns that write to the same registers do not have the same priority. You can effectively remove it by returning zero if all the insns on the ready list would cause a conflict. The scheduler will then force the next cycle. Seriously, all this exists in c6x.c, you just need to copy that code. Bernd
RE: Defining scheduling resource constraint
-Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 07 November 2012 11:24 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint You can effectively remove it by returning zero if all the insns on the ready list would cause a conflict. The scheduler will then force the next cycle. Makes sense... Seriously, all this exists in c6x.c, you just need to copy that code. I understand that I can copy the code. I could even just go ahead and change haifa-sched.c however I am just trying to understand how all these scheduling hooks work and why the docs say something and I was seeing something else. I am sorry if I was a nuisance. Thanks for your help. -- Paulo Matos
RE: Defining scheduling resource constraint
-Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 05 November 2012 16:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the bookkeeping yourself - keep track of which registers have been set in the current cycle, and ensure insns which set the same registers go to the back of the queue and aren't considered anymore until the next cycle. 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. 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. 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. Any suggestions on how to remove this instruction? Or do I need to keep more scheduling state in the backend in order to do this properly? Cheers, Paulo Matos
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. 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. Bernd
Re: Defining scheduling resource constraint
Quoting Paulo Matos pma...@broadcom.com: Hello, I am experience a problem in GCC4.7 scheduler whereby the scheduler is issuing two instructions that write with a cond_exec to the same register. It ends up looking like this: Cond_exec p1 != 0 : r2 - r2 and 0xf8 Cond_exec p0 != 0: r2 - 0x10 This cannot happen, but I am unsure about which hook can be used to tell the scheduler about this. Sounds like it could be one of these issues: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044 http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00743.html
Re: Defining scheduling resource constraint
On 11/05/2012 03:51 PM, Paulo Matos wrote: Hello, I am experience a problem in GCC4.7 scheduler whereby the scheduler is issuing two instructions that write with a cond_exec to the same register. It ends up looking like this: Cond_exec p1 != 0 : r2 - r2 and 0xf8 Cond_exec p0 != 0: r2 - 0x10 This cannot happen, but I am unsure about which hook can be used to tell the scheduler about this. Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the bookkeeping yourself - keep track of which registers have been set in the current cycle, and ensure insns which set the same registers go to the back of the queue and aren't considered anymore until the next cycle. Bernd
RE: Defining scheduling resource constraint
-Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: 05 November 2012 16:32 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint This cannot happen, but I am unsure about which hook can be used to tell the scheduler about this. Sounds like it could be one of these issues: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044 http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00743.html Thanks for the references. I haven't looked into it but the patch attached to the bug doesn't actually fix the symptom so I am assuming it's not the problem. On the other hand I see that the patch is quite old and never managed into GCC so maybe the problem has been fixed somewhere else. Do you know why the patch never made it into GCC? Paulo Matos
RE: Defining scheduling resource constraint
-Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 05 November 2012 16:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the You mean sched_reorder, right? -- Paulo Matos
Re: Defining scheduling resource constraint
On 11/05/2012 06:11 PM, Paulo Matos wrote: -Original Message- From: Bernd Schmidt [mailto:ber...@codesourcery.com] Sent: 05 November 2012 16:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: Defining scheduling resource constraint Depends on why it schedules them in the same cycle. Either there's an output dependency, in which case your target's adjust_cost needs to ensure it doesn't have cost zero. Or maybe the scheduler proved that the conditions are mutually exclusive and didn't add such a dependency. In that case, if the machine really disallows this case, you'll probably need to define the sched_reorg hooks and maybe variable_issue and do the You mean sched_reorder, right? Right. Bernd
