[llvm-dev] Optimization of successive constant stores
David Jones via llvm-dev
llvm-dev at lists.llvm.org
Fri Dec 11 08:32:50 PST 2015
Consider the following:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
%UodStructType = type { i8, i8, i8, i8, i32, i8* }
define void @test(%UodStructType*) {
%2 = getelementptr inbounds %UodStructType* %0, i32 0, i32 0
store i8 1, i8* %2, align 8
%3 = getelementptr inbounds %UodStructType* %0, i32 0, i32 1
store i8 2, i8* %3, align 1
%4 = getelementptr inbounds %UodStructType* %0, i32 0, i32 2
store i8 3, i8* %4, align 2
%5 = getelementptr inbounds %UodStructType* %0, i32 0, i32 3
store i8 4, i8* %5, align 1
ret void
}
If I run this through opt -O3, it passes through unchanged.
However, I would think that it would be profitable to combine the stores
into a single instruction, e.g.:
define void @test(%UodStructType*) {
%2 = bitcast %UodStructType* %0 to i32*
store i32 0x04030201, i32* %2, align 8
ret void
}
I don't see any optimization that would do this.
Interestingly, if I store the same 8-bit constant in all four bytes, then
MemCpyOpt will indeed convert this to a 32-bit store.
Am I doing something wrong, or is there really no optimization pass that
can clean this up?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/17827054/attachment.html>
More information about the llvm-dev
mailing list