[PATCH] D76434: [SCEV] Query for immediate cost in Expander

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 20 07:32:41 PDT 2020


lebedev.ri added a comment.

In D76434#1933359 <https://reviews.llvm.org/D76434#1933359>, @samparker wrote:

> > Do we model rthrougput for constants elsewhere?
>
> I guess that depends on who 'we' are because, again, different backends will be modelling different things.


Sorry, i meant llvm transforms in general, not backends.

> Why the focus on throughput now anyway? When this code was using getOperationCost,
>  it would have been getting some performance/code size cost,
>  which I expect most backends will be modelling for constants.
>  And I'm not really sure why throughput is specifically important here,
>  we're not concerning ourselves with the throughput of casts and compares, right?

We have 3 cost models - latency, size and rthroughput.
My aspirational goal in this scevexpander budget was: "how much more computations are we willing to do without it being too much of a burden?"
Size model isn't really applicable here - we *could* lower any sequence into a libcall, regardless of it's native instruction count.
Likewise i'm not sure we're really after latency here, which leaves us with rthroughput.
But we can't subtract oranges from cucumbers, so all cost modelling should be consistently using rthroughput cost model.
Thus i'm asking, what does `getIntImmCost()` model? rthroughput or size?

>> Let's take a step back here. How about we simply revert D73501 <https://reviews.llvm.org/D73501>?
> 
> Sounds good to me, although I still need to prod around here to see if codegen risk being erratic in the future.




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76434/new/

https://reviews.llvm.org/D76434





More information about the llvm-commits mailing list