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

[Quentin Colombet]

On Aug 19, 2013, at 6:08 PM, Sean Silva <silvas at purdue.edu> wrote:

> 
> 
> 
> On Mon, Aug 19, 2013 at 8:35 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> Hi,
> 
> Here is a patch that implements the slicing of a load into two smaller loads when the elements are next to each other in memory.
> The original motivation as well as the discussion of why we came up with this patch can be found here:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064769.html
> 
> 
> ** Motivation **
> 
> To give a bit of context, the motivation was to get rid of truncate and shift right instructions that get in the way of paired load or floating point load.
> E.g.,
> Consider the following example:
> struct Complex {
> 	float real;
> 	float imm;
> };
> 
> When accessing a complex, llvm was generating a 64-bits load and the imm field was obtained by a trunc(lshr) sequence, resulting in poor code generation, at least for x86.
> 
> 
> Interesting. I saw something similar ("extract-fields-from-chunk-of-bits") while investigating the issue reported in PR16739 (the second IR example in the bug report is an example), except that the trunc/lshr's were being created by GVN and not by SROA. <http://llvm.org/bugs/show_bug.cgi?id=16739>
That’s indeed interesting.
I had a quick look at PR16739, and this transformation could apply if we extend it to floating point type. Currently, we abort the transformation is the load is not an int type.

-Quentin

> 
> -- Sean Silva

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