[PATCH] D75981: [LV] Allow large RT checks, if they are a fraction of the scalar cost.

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

It is *really* sad to see these two patches to be stuck :(

In D75981#2903756 <https://reviews.llvm.org/D75981#2903756>, @ebrevnov wrote:

> Sorry for long silence. Got into hospital with COVID-19 for almost a month.
>
>>> In D75981#2662881 <https://reviews.llvm.org/D75981#2662881>, @ebrevnov wrote:
>>>
>>>> I don't really understand why we need this separate heuristic for runtime checks. Why don't we simply add cost of runtime checks (possibly with some small scaling to be safe) to total cost of vector loop and just use existing cost model to decide?
>>>
>>> That's a good point, but I think that would be better as separate change, because that's a more aggressive change than replacing existing limit. IIUC that's more in line with your D71053 <https://reviews.llvm.org/D71053>.
>
> You are right, I'm essentially asking to follow D71053 <https://reviews.llvm.org/D71053>. First of all, in sake of doing progress I'm not going to block this change if you promise continue working on cost model driven approach.
> But I personally think that it would save a lot of time if we go with cost model based approach in the first place because most time consuming thing would be fixing performance regressions and not the implementation itself. I will leave it on you to decide :-).
>
>>>> Please add regression tests from https://reviews.llvm.org/D71053 to this change set as well.
>>>
>>> I'm not sure that there's much benefit at the moment, because there will be no changes. The focus of those tests seems to be more about vectorizing small trip count loops with an epilogue and not the cost of memory runtime checks (there are no memory runtime checks for the test I think)
>
> I believe both test cases have vectorization with runtime checks. Look for "; CHECK:       vector.memcheck:"

I think the goals of these two patches are largely correlated.

I think the main problem is that it isn't quite obvious why hard cut-offs on the runtime check complexity exist.
I guess, to not generate some very large and ridiculous checks.
But clearly, the current cut-offs are just bogusly low.
But i also guess simply bumping them won't really solve the problem,
so i guess we need to redefine them. But what is the right metric,
especially if the trip count is not constant?
Cost of a single scalar loop iteration?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75981