summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2010-04-15 04:48:01 +0000
committerChris Lattner <sabre@nondot.org>2010-04-15 04:48:01 +0000
commit4041ab6e007201a69128886d6942416f2ce04e97 (patch)
tree21029ff6a96b3ec75c556042a20882bc72ed2000 /clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
parent913c998703231667cdd2befac755e19f9b6f1816 (diff)
downloadbcm5719-llvm-4041ab6e007201a69128886d6942416f2ce04e97.tar.gz
bcm5719-llvm-4041ab6e007201a69128886d6942416f2ce04e97.zip
Implement rdar://7860110 (also in target/readme.txt) narrowing
a load/or/and/store sequence into a narrower store when it is safe. Daniel tells me that clang will start producing this sort of thing with bitfields, and this does trigger a few dozen times on 176.gcc produced by llvm-gcc even now. This compiles code like CodeGen/X86/2009-05-28-DAGCombineCrash.ll into: movl %eax, 36(%rdi) instead of: movl $4294967295, %eax ## imm = 0xFFFFFFFF andq 32(%rdi), %rax shlq $32, %rcx addq %rax, %rcx movq %rcx, 32(%rdi) and each of the testcases into a single store. Each of them used to compile into craziness like this: _test4: movl $65535, %eax ## imm = 0xFFFF andl (%rdi), %eax shll $16, %esi addl %eax, %esi movl %esi, (%rdi) ret llvm-svn: 101343
Diffstat (limited to 'clang/lib/CodeGen/CGRecordLayoutBuilder.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud