aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenModule.cpp
diff options
context:
space:
mode:
authorHal Finkel <hfinkel@anl.gov>2014-08-01 01:02:01 +0000
committerHal Finkel <hfinkel@anl.gov>2014-08-01 01:02:01 +0000
commit3604bf7fe7a263b9a4f1fbfc284fb205f2a5de33 (patch)
tree0b459dbad6954e13814d176e2ba49e1542137c25 /clang/lib/CodeGen/CodeGenModule.cpp
parent71ff3f223f96a8ec2aa766144daddc18c5a1c062 (diff)
downloadllvm-3604bf7fe7a263b9a4f1fbfc284fb205f2a5de33.zip
llvm-3604bf7fe7a263b9a4f1fbfc284fb205f2a5de33.tar.gz
llvm-3604bf7fe7a263b9a4f1fbfc284fb205f2a5de33.tar.bz2
[PowerPC] Recognize consecutive memory accesses from intrinsics
When generating unaligned vector loads, we need to search for other loads or stores nearby offset by one vector width. If we find one, then we know that we can safely generate another aligned load at that address. Otherwise, we must generate the next load using an offset of the vector width minus one byte (so we don't read off the end of the allocation if the base unaligned address happened to be aligned at runtime). We had previously done this using only other vector loads and stores, but did not consider the PowerPC-specific vector load/store intrinsics. Now we'll also consider vector intrinsics. By itself, this change is a feature enhancement, but is a necessary step toward fixing the underlying problem behind PR19991. llvm-svn: 214469
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions