[PATCH] D23169: [LV] Unify vector and scalar maps

Adam Nemet via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 15 13:54:55 PDT 2016


anemet added a comment.

Matt, I also had some comments from earlier that I've never sent out.  This was about the future direction of get{Scalar,Vector}Value:

In https://reviews.llvm.org/D23169#506915, @mssimpso wrote:

> > Anyhow, this all seems like the property of WidenMap, so I am wondering how hard it would be to pull getScalarValue and getVectorValue under that class.  (I am also not sure that hiding the class inside InnerLoopVectorizer in a .cpp file is really adding anything but certainly hurts readability as the class is growing.)
>
>
> I think moving getVectorValue and getScalarValue into WidenMap might be tricky. The issue is that getVectorValue uses getBroadcastInstrs, which is a member of InnerLoopVectorizer, and hasStride from LoopVectorizationLegality. For getBroadcastInstrs, would we pass an InnerLoopVectorizer* to WidenMap? Alternatively, we could probably make getBroadcastInstrs into a utility (maybe in VectorUtils?). What about hasStride? What do you think?


Yeah, hasStride does *not* seem to belong to WM.  We could have a wrapper of WM's getVectorValue in ILV that just swaps in the speculated stride value before calling WM::getVectorValue.

getBroadcastInstrs on the other hand probably does belong to WM because it's part of the whole picture how values are mapped.  So probably making it stand-alone utility is the way to go.

Anyhow this all is certainly for another patch.  I just wanted to see what you guys thought about moving even more of the mapping responsibility out of ILV to WM.


https://reviews.llvm.org/D23169





More information about the llvm-commits mailing list