[PATCH][instcombine]: Slice a big load in two loads when the element are next to each other in memory.

[Quentin Colombet]

After discussing with Chandler off-line, we decided to perform the load slicing at isel time.
Thus, this patch has been reverted in r190891.

-Quentin

On Sep 17, 2013, at 2:10 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Mon, Aug 26, 2013 at 1:08 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> After looking into SROA, Nadav and I agreed that it does the right thing.
> Therefore, the initial proposed patch is still the one to be reviewed.
> 
> Very, very sorry for the late comment here. I misunderstood this comment and the result.
> 
> I agree that SROA is correct here, and I also think that this should be the canonical form. With the LLVM memory model, it is very hard to merge two smaller loads back together if that is ever profitable. It is essentially impossible in many cases to merge two smaller stores back together if that is ever profitable. As such, it is very useful to preserve the widest known-safe load and store size as far as possible in the optimizer. At least getting it to the backend where the cost factor for various load and store operations is known is essential.
> 
> Can we canonicalize toward the wide loads and stores with appropriate masking to extract narrow values, and then match these back to the small stores in the backend?
> 
> Both SROA and optimal bitfield code generation rely on this (at least for x86) so changing it will regress some things.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130917/389603e0/attachment.html>