[PATCH] D37579: [InstCombine] Fix PR21780 Expansion of 256 bit vector loads fails to fold into shuffles

Tue Nov 26 20:32:54 PST 2019

jdoerfert added a subscriber: Tyker.
jdoerfert added a comment.
Herald added a subscriber: hiraditya.

In D37579#1654899 <https://reviews.llvm.org/D37579#1654899>, @RKSimon wrote:

> Adding @jdoerfert who can probably advise regarding whether Attributor will handle all of this

First, sorry for not reacting sooner.

---

Long story short, I would prefer a more generic solution.

The way I understand this patch is that it tries to "remember" knowledge we are about to loose due to a transformation, correct? (If not, my next paragraphs are probably way off.)

To answer the Attributor question: 
The Attributor will tie dereferenceable and nonnull knowledge to arguments and call site return values (especially the latter is not properly working due to some stuff I don't want to get into).
That means, if the base pointer is an argument (like in the test cases) and the accesses are in the must-be-executed-context of the argument (like in the test cases) it will work. If either is
not the case, it won't. That is the problem I would fix.

A similar situation arose recently in D69477 <https://reviews.llvm.org/D69477>. While we got a temporary solution in there, I think my response to it is adequate here as well https://reviews.llvm.org/D69477#1724399 .
I am in contact with @Tyker on this but I haven't found the time to write an RFC. If more people are interested in a generic way to preserve information I'd be happy to share my thoughts so far an help on a design.

To give you an idea, I was currently thinking about something along the lines of: `llvm.assume() ["derefereceable"(%p, 8), "derefereceable"(%gep, 4), "align"(%p, 16) ]`

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

https://reviews.llvm.org/D37579