On 02/18/15 01:03, Maxim Kuvyrkov wrote:
The way SCHED_GROUP_P instructions have been handled historically is
by combination of two artifacts: (1) removing all dependencies for
instructions inside SCHED_GROUP sequence but the one to next insn,
and (2) maintaining a fast track for SCHED_GROUP ins
On Feb 17, 2015, at 9:43 AM, Jeff Law wrote:
> On 02/11/15 02:20, James Greenhalgh wrote:
>>
>> On Mon, Feb 09, 2015 at 11:16:56PM +, Jeff Law wrote:
>>> On 02/06/15 05:24, James Greenhalgh wrote:
---
2015-02-06 James Greenhalgh
* haifa-sched.c (recompute_tod
On 02/11/15 02:20, James Greenhalgh wrote:
On Mon, Feb 09, 2015 at 11:16:56PM +, Jeff Law wrote:
On 02/06/15 05:24, James Greenhalgh wrote:
---
2015-02-06 James Greenhalgh
* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency,
On Mon, Feb 09, 2015 at 11:16:56PM +, Jeff Law wrote:
> On 02/06/15 05:24, James Greenhalgh wrote:
> >
> > ---
> > 2015-02-06 James Greenhalgh
> >
> > * haifa-sched.c (recompute_todo_spec): After applying a
> > replacement and cancelling a dependency, also clear the
> > SCHED_GR
On Feb 10, 2015, at 7:16 AM, Jeff Law wrote:
> On 02/06/15 05:24, James Greenhalgh wrote:
>>
>> ---
>> 2015-02-06 James Greenhalgh
>>
>> * haifa-sched.c (recompute_todo_spec): After applying a
>> replacement and cancelling a dependency, also clear the
>> SCHED_GROUP_P flag.
>
On 02/06/15 05:24, James Greenhalgh wrote:
---
2015-02-06 James Greenhalgh
* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency, also clear the
SCHED_GROUP_P flag.
My worry here would be that we might be clearing a SCHED_GROU
