Ian Lance Taylor wrote:
"Amker.Cheng" <amker.ch...@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.
