This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: what does the calling for min_insn_conflict_delay mean
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.