[PATCH] D45552: [NFC][LV][LoopUtil] Move LoopVectorizationLegality to its own file

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 30 03:28:56 PDT 2018


rengolin added a comment.

In https://reviews.llvm.org/D45552#1082360, @hsaito wrote:

> In this case, the most immediate client for us is actually our internal fast-track VPLan vectorizer (it's outside of LV so that we don't mess up LV accidentally),


Still inside Transform, so should be fine.

> but we'd like other optimizers aware of potential vectorization (or lack of it) to unleash more power (e.g., fusion, distribution, etc.).

More specifically?

> LoopVectorizationLegality::canVectorize() is a straightforward interface for any client to use for such purposes, as a starter.

I'm not disagreeing with you. :)

> Seriously, LVL is a standalone stuff that we could create an Analysis pass --- pending Induction/RecurrenceDescriptors stuff it is dependent on).

The pending part that is the trouble. We'd have to extract them before a move, but we'd also have to have a reason other than "it looks like an analysis pass".

I agree it does, I agree it would be interesting to move it up, but I have no concrete example of what could use it on the current code, so I have no reason to move it up.

> We can't move it to a higher ground without first open sourcing non-vectorizer client use?????

I'm not sure what you're referring to, but if you have downstream code that needs it, then yes, you would have to show it (in the form or an RFC and a review) to help us understand your use.

For now, it doesn't really matter where it is, so we don't move unnecessarily.

Hope this makes sense.

cheers,
--renato


Repository:
  rL LLVM

https://reviews.llvm.org/D45552





More information about the llvm-commits mailing list