[PATCH] D81766: [VectorCombine] try to create vector loads from scalar loads

[Nikita Popov via Phabricator via llvm-commits]

nikic added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/VectorCombine.cpp:130
+  // We can aggressively convert to the vector form because the backend will
+  // invert this transform if it does not result in a performance win.
+  if (OldCost < NewCost)
----------------
spatel wrote:
> nikic wrote:
> > Will other middle end passes be able to handle this well as well? I don't have anything specific in mind here, but would suspect that some passes will be able to deal with a "load" better than a "bitcast, load, extractelement" sequence.
> Other middle end passes almost certainly will *not* handle this as well. :)
> It's not quite the same pattern/problem since we're creating vector ops here, but that's what led to removing the generic LoadCombine IR pass ( http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html ).
> I'm assuming that VectorCombine is running late enough (after GVN, etc.) that we've already done all of the general IR optimizations that can be done with the narrow ops. I could try to cobble some PhaseOrdering tests to enforce it, but these would be negative tests currently.
I'm not sure how safe that assumption is. For example, in Rust it is possible for code to go through two ThinLTO links at different hierarchy levels. In that case the first one would convert everything to vector loads (given ample dereferencability information), and the second one might have trouble optimizing based on that.


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

https://reviews.llvm.org/D81766