diff options
author | Quentin Colombet <qcolombet@apple.com> | 2013-09-17 16:57:34 +0000 |
---|---|---|
committer | Quentin Colombet <qcolombet@apple.com> | 2013-09-17 16:57:34 +0000 |
commit | 0119f3df9c2016664540f8e3be89fe5cd54cbb07 (patch) | |
tree | dbcfd1cafb1d905de869cd63e54b3904d9a36904 /test/Analysis/CostModel | |
parent | 2ff37c701ebb4e4d593df085fe8bb60f2d6d340a (diff) | |
download | external_llvm-0119f3df9c2016664540f8e3be89fe5cd54cbb07.zip external_llvm-0119f3df9c2016664540f8e3be89fe5cd54cbb07.tar.gz external_llvm-0119f3df9c2016664540f8e3be89fe5cd54cbb07.tar.bz2 |
[InstCombiner] Slice a big load in two loads when the elements are next to each
other in memory.
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.
The idea is to declare that two load instructions is the canonical form for
loading two arithmetic type, which are next to each other in memory.
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.
<rdar://problem/14477220>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190870 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Analysis/CostModel')
0 files changed, 0 insertions, 0 deletions