Re: what does the calling for min_insn_conflict_delay mean

[Vladimir Makarov <vmakarov@redhat.com>]

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.