How to define 2 bypasses for a single pair of insn_reservation

[Maxim Kuvyrkov]

Ye, Joey wrote:
> Maxim and Vladimir Wrote:
>>>> Anyone can help me through this please?
>>>>   
>>> It was supposed to have two latency definitions at most (one in 
>>> define_insn_reservation and another one in define_bypass).  That time it 
>>> seemed enough for all processors supported by GCC.  It also simplified 
>>> semantics definition when two bypass conditions returns true for the 
>>> same insn pair.
>>>
>>> If you really need more one bypass for insn pair, I could implement 
>>> this.  Please, let me know.  In this case semantics of choosing latency 
>>> time could be
>>>
>>> o time in first bypass occurred in pipeline description whose condition 
>>> returns true
>>> o time given in define_insn_reservation
>> I had a similar problem with ColdFire V4 scheduler model and the 
>> solution for me was using adjust_cost() target hook; it is a bit 
>> complicated, but it works fine.  Search m68k.c for 'bypass' for more 
>> information, comments there describe the thing in sufficient detail.

> Maxim, I read your implementation in m68k.c. IMHO it is a smart but
> tricky solution. For example it depends on the assumption that
> targetm.sched.adjust_cost () immediately called after bypass_p().

Yes, it does depend on this assumption and the comment states exactly that.

> Also the redundant check and calls to min_insn_conflict_delay looks
> inefficient.

Which check[s] do you have in mind, the gcc_assert's?  Also, out of 
curiosity, what is inefficient about the use of min_insn_conflict_delay?

For the record, min_insn_conflict delay has nothing to do with emulating 
two bypasses; this tweak makes scheduler faster by not adding 
instructions to the ready list which makes haifa-sched.c:max_issue() do 
its exhaustive-like search on a smaller set.

> I'd prefer to extend semantics to support more than one
> bypass.

Don't get me wrong, I'm not against adding support for N>1 bypasses; it 
is not that easy though ;) .

--
Maxim