[llvm] TargetSchedule: correct latency by cycles elapsed from def to use (PR #74088)

[Ramkumar Ramachandra via llvm-commits]

artagnon wrote:

> I think the result of `computeOperandLatency` should not depend on the current position of `DefMI` and `UseMI`. It should just tell you how many cycles must elapse after `DefMI` is issued, until `UseMI` could be issued without stalling.

I agree with your second statement, but since we don't have a scheduling model when we return fallback latencies, what if DefMI is scheduled very far away from UseMI (by very far away, I mean that DefMI has already finished issuing, and UseMI can use its result)? In this case, the fallback latency returned is the latency of DefMI, which is far too conservative.

> Anything to do with the current position of the instructions should be handled by the caller (presumably MachineScheduler or some other scheduler implementation).

Ofcourse, and in the non-fallback cases, computeOperandLatency returns the right number of cycles, since the scheduling model is available. The issue I'm trying to solve with this patch is the far-too-conservative latency returned by computeOperandLatency when there is no scheduling model available, and unfortunately, this does get hit in a lot of cases.

https://github.com/llvm/llvm-project/pull/74088