what does the calling for min_insn_conflict_delay mean

what does the calling for min_insn_conflict_delay mean

[Amker.Cheng]

Hi :
   In function new_ready, it calls to min_insn_conflict_delay with
"min_insn_conflict_delay (curr_state, next, next)".
But the function's comments say that it returns minimal delay of issue of
the 2nd insn after issuing the 1st in given state.
Why the last two parameter for the call are both "next"?
seems conflict with the comments.

Thanks.

-- 
Best Regards.

Re: what does the calling for min_insn_conflict_delay mean

[Ian Lance Taylor]

"Amker.Cheng" <amker.cheng@gmail.com> writes:

>    In function new_ready, it calls to min_insn_conflict_delay with
> "min_insn_conflict_delay (curr_state, next, next)".
> But the function's comments say that it returns minimal delay of issue of
> the 2nd insn after issuing the 1st in given state.
> Why the last two parameter for the call are both "next"?
> seems conflict with the comments.

This change dates back to the first DFA scheduler patch.  It does seem a
little odd, particularly as the call in new_ready is the only use of
min_insn_conflict_delay.  CC'ing vmakarov in case he remembers anything
about this old code.

Ian

Re: what does the calling for min_insn_conflict_delay mean

[Vladimir Makarov]

Ian Lance Taylor wrote:
> "Amker.Cheng" <amker.cheng@gmail.com> writes:
>
>   
>>    In function new_ready, it calls to min_insn_conflict_delay with
>> "min_insn_conflict_delay (curr_state, next, next)".
>> But the function's comments say that it returns minimal delay of issue of
>> the 2nd insn after issuing the 1st in given state.
>> Why the last two parameter for the call are both "next"?
>> seems conflict with the comments.
>>     
>
>   
Amker, thanks for finding this issue.
> This change dates back to the first DFA scheduler patch.  It does seem a
> little odd, particularly as the call in new_ready is the only use of
> min_insn_conflict_delay.  CC'ing vmakarov in case he remembers anything
> about this old code.
>   
I've not remembered this.  I guess  it was a result of long period of 
transition from the old pipeline hazard recognizier to the DFA one which 
required to rewrite all old pipeline descriptions.

Also after starring at this code for some time,  I don't like this 
code.  Now I'd use min_issue_delay (curr_state, next) which is delay of  
issuing  next in the current function unit reservation state instead of  
min_insn_conflict_delay (curr_state, next, next) which is a delay of 
issuing the first insn (next) after issuing the second insn (next) on a 
free processor (when all function units are free).  Probably it was a 
typo.  Although I think that such change (in many other conditions to 
move insn speculatively to the ready list) will not give a visible 
improvement for most processors, I'll try it.

It looks to me that probably I had also some plans for usage of 
min_insn_conflict_delay, but I forgot them because it was long ago.

Re: what does the calling for min_insn_conflict_delay mean

[Amker.Cheng]

On Tue, Sep 22, 2009 at 11:50 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> Ian Lance Taylor wrote:
>>
>> "Amker.Cheng" <amker.cheng@gmail.com> writes:
>>
>>
>>>
>>>   In function new_ready, it calls to min_insn_conflict_delay with
>>> "min_insn_conflict_delay (curr_state, next, next)".
>>> But the function's comments say that it returns minimal delay of issue of
>>> the 2nd insn after issuing the 1st in given state.
>>> Why the last two parameter for the call are both "next"?
>>> seems conflict with the comments.
>>>
>>
>>
>
> Amker, thanks for finding this issue.
It's great pleasure if can help anything.

>>
>> This change dates back to the first DFA scheduler patch.  It does seem a
>> little odd, particularly as the call in new_ready is the only use of
>> min_insn_conflict_delay.  CC'ing vmakarov in case he remembers anything
>> about this old code.
>>
>
> I've not remembered this.  I guess  it was a result of long period of
> transition from the old pipeline hazard recognizier to the DFA one which
> required to rewrite all old pipeline descriptions.
>
> Also after starring at this code for some time,  I don't like this code.
>  Now I'd use min_issue_delay (curr_state, next) which is delay of  issuing
>  next in the current function unit reservation state instead of
>  min_insn_conflict_delay (curr_state, next, next) which is a delay of
> issuing the first insn (next) after issuing the second insn (next) on a free
> processor (when all function units are free).  Probably it was a typo.
>  Although I think that such change (in many other conditions to move insn
> speculatively to the ready list) will not give a visible improvement for
> most processors, I'll try it.
>
> It looks to me that probably I had also some plans for usage of
> min_insn_conflict_delay, but I forgot them because it was long ago.
>
>

Is it the delay of issuing next in the current reservation state which
expected here?

seems the call to min_insn_conflict_delay does nothing harm, except
may result in
more or less speculative motions(which are all valid ones).

-- 
Best Regards.