[PATCH] [InstCombine] Combine adjacent i8 loads.

Arnold Schwaighofer aschwaighofer at apple.com
Fri May 2 12:00:35 PDT 2014


On May 2, 2014, at 10:17 AM, Andrew Trick <atrick at apple.com> wrote:

> 
> On May 2, 2014, at 9:32 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
> 
>> I don't think the above transformation (building a value of a bigger type from a smaller type) is going to interfere with regular SLP vectorization because we start bottom-up (sink to source) and we don't have patterns that would start at an "or reduction" (bigger than 2 operations). If we implement a second transformation that starts from loads and widens operations top-down, then, I agree with Andy, we would have to be careful about phase ordering.
> 
> My concern was that a chain that appeared profitable before no longer appears profitable because we don’t see the scalar loads and think we need vector insertion without realizing it can be folded away. If you don’t think that’s an issue, or can be easily fixed then I believe you.

To clarify, I agree with Andy that we can run into phase ordering problems if we implement this as a separate pass.

What I wanted to say above is that if we model this transformation in the SLP vectorizer then we should not have phase ordering problems. However, I don’t think modeling this in the SLP vectorizer (adding complexity) is justified just by swap (we should do this as a dagcombine).  If on the other hand we expect longer chains leading to a load that could be vectorized then it might make sense thinking about adding complexity to the slp vectorizer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140502/2b8974dd/attachment.html>


More information about the llvm-commits mailing list