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

[Hideki Saito via Phabricator via llvm-commits]

hsaito added a comment.

In https://reviews.llvm.org/D45552#1082592, @rengolin wrote:

> 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.


That's why I didn't insist to move Legal to Analysis.

>> 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?

For example, in loop fusion scenarios, doing this is not a rocket science.

if (LVL_for_Loop1->canVectorize() == LVL_for_Loop2->canVectorize()) {

  // fusion doesn't have to care much about what vectorizer would do downstream.

} else {

  // we'd like to make sure fusion will gain more than vectorizing the loop that canVectorize() --- else don't fuse.

}

This is a chicken-egg problem. In my opinion, since vectorizer has so much performance impact, vectorizer's analysis aspect should be made available for others for "easier reuse". Next thing I'd like to move up to a higher ground is CostModel. I'll be sure to send in an RFC for that.

Thanks,
Hideki


Repository:
  rL LLVM

https://reviews.llvm.org/D45552