[PATCH] D36896: [TargetTransformInfo] Call target getMemoryOpCost for LoadInst from getUserCost

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D36896#849335, @Carrot wrote:

> In https://reviews.llvm.org/D36896#847686, @hfinkel wrote:
>
> > We currently have two cost models in TTI. One is for the vectorizer and it is supposed to measure normalized reciprocal throughputs. The other model, the "user cost" model, is used by the inliner, the loop unroller, and a few other things. This model measures some less-well-defined combination of performance factors (thoughput/latency) and code size. I don't know whether tying these things together makes sense. At the risk of going down some rabbit hole, we should probably answer that question. If it does make sense, we should tie them together more completely than just for memory operations.
>
>
> Thank you for the clarification that they are actually belong to two different cost models. 
>  My problem is in SimplifyCFG(if conversion), I want to compute the latency of a dependence chain. Currently I use getUserCost for each instruction, but I get 1 for memory load, it is much lower than reality, the big gap makes it almost useless. So which API should I use to get a more precise latency of instructions?


We don't have one (at the IR level). We should. I really want to see TTI have one cost model that returns <reciprocal throughput, latency, size>, all normalized, for each query. Then each client would be able to pick the right numbers for what it wants. While I dislike suggesting that someone take on a big project to fix a small problem, maybe we can do this incrementally somehow, so that we can keep things moving in the right direction. I suggest that you change the TTI cost interfaces to return some kind of tuple or structure, and then, make all of the latencies default to 1 for scalar operations, 5 for FP/vector ops (or 4 or 6 or whatever you think makes a reasonable default), and STI.getSchedModel().LoadLatency for loads. That will get you the right load latency, and provide an interface we can improve over time to get latency estimates for the other operations.


https://reviews.llvm.org/D36896