aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Transforms/Vectorize
diff options
context:
space:
mode:
authorQuentin Colombet <qcolombet@apple.com>2013-09-17 16:57:34 +0000
committerQuentin Colombet <qcolombet@apple.com>2013-09-17 16:57:34 +0000
commit0119f3df9c2016664540f8e3be89fe5cd54cbb07 (patch)
treedbcfd1cafb1d905de869cd63e54b3904d9a36904 /lib/Transforms/Vectorize
parent2ff37c701ebb4e4d593df085fe8bb60f2d6d340a (diff)
downloadexternal_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 'lib/Transforms/Vectorize')
0 files changed, 0 insertions, 0 deletions