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

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Apr 29 10:45:26 PDT 2018


rengolin added a comment.

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

> A public header has zero impact in compile time for the files that are not including it, for obvious reasons.


Yup, that's not the problem.

> I really would like other optimizers start thinking about whether vectorization is even possible or not and act accordingly ---- and for that I'd want to lower the bar for people wanting to do it. Moving the code from one place to another has a psychological barrier for many people. Remember, originally, I wanted to move this to Analysis, to make it easy to create an Analysis pass out of it if somebody wants that.

It's not just psychological, it's organisational. A header that is inside a source directory is harder to include than one that is inside an include directory (needs ../.. on the path, or change the include path). That extra step is a giveaway for reviewers that you may be trying to rely on internal logic that should not escape its original domain.

In this case, LoopUtils and others were literally created *just* for the loop vectoriser. Any other pass wanting to use those libraries will have to consider how they work, and some work is bound to be needed on both loop vectoriser and new user.

That extra difficulty is intended as a barrier to avoid misunderstandings (and future code gen failures), so as to make *every* "use beyond original intention" explicit and thought through.

This is why we don't move any local header to includes without a clear user, a clear use case and refactoring with a clear purpose.

I agree with you that this functionality belongs to higher ground, but we need to know what the other users will be like before we can move it, to avoid accidental users.

cheers,
--renato


Repository:
  rL LLVM

https://reviews.llvm.org/D45552





More information about the llvm-commits mailing list