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

[Quentin Colombet]

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.


** Proposed Solution **

Eli Friedman suggested that:
“[...] two scalar loads at a constant offset from each other are pretty easy to detect for the sorts of passes that like to mess with loads.  So we probably just want to declare that two load instructions is the canonical form for loading two [arithmetic type] which are next to each other in memory, and do this transform on IR for all targets.[…]”

This patch implements that solution as an instcombine transformation. Also as Eli suggested too, it makes sure the generated loads do not overlap.

The patch includes a test case that reproduces the initial motivating test case (an add of  complexes), plus a bunch of stress tests that check that the (extreme) slicing is correct for big endian and little endian targets.


** Performance **

I have attached the performance numbers for x86-64 (macbook pro core i7 @2.9Hz) for the llvm test-suite.
I only reported the numbers were the transformation was actually applied.

The raw numbers where the transformation applied can be found in:
mod.report.simple.txt: for llvm r188676.
mod.report.simple.with: for llvm r188676 + this patch.

Also mod.comparison.txt compares these numbers for tests that ran for at least 1s (otherwise it is too noisy), lower is better.

The few regressions reported are false positive, i.e., I reran the tests and it is just that the runtime numbers are not that precise.

Thanks for the feedbacks.

Cheers,
-Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mod.comparison.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mod.report.simple.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0001.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod.report.simple.with
Type: application/octet-stream
Size: 26460 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InstCombineLoadSlicing.svndiff
Type: application/octet-stream
Size: 28817 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/0c0c640e/attachment-0004.html>