[LICM] Infer proper alignment from loads during scalar promotion
authorPhilip Reames <listmail@philipreames.com>
Fri, 1 Mar 2019 18:45:05 +0000 (18:45 +0000)
committerPhilip Reames <listmail@philipreames.com>
Fri, 1 Mar 2019 18:45:05 +0000 (18:45 +0000)
commit2226e9a745b91bdd8a97cb508c1f90c411f3e965
tree482b2aff062373252a7d120e527e8fa296abcbbc
parent06ed38517e68876277d4accbcc538a016c58f9a8
[LICM] Infer proper alignment from loads during scalar promotion

This patch fixes an issue where we would compute an unnecessarily small alignment during scalar promotion when no store is not to be guaranteed to execute, but we've proven load speculation safety. Since speculating a load requires proving the existing alignment is valid at the new location (see Loads.cpp), we can use the alignment fact from the load.

For non-atomics, this is a performance problem. For atomics, this is a correctness issue, though an *incredibly* rare one to see in practice. For atomics, we might not be able to lower an improperly aligned load or store (i.e. i32 align 1). If such an instruction makes it all the way to codegen, we *may* fail to codegen the operation, or we may simply generate a slow call to a library function. The part that makes this super hard to see in practice is that the memory location actually *is* well aligned, and instcombine knows that. So, to see a failure, you have to have a) hit the bug in LICM, b) somehow hit a depth limit in InstCombine/ValueTracking to avoid fixing the alignment, and c) then have generated an instruction which fails codegen rather than simply emitting a slow libcall. All around, pretty hard to hit.

Differential Revision: https://reviews.llvm.org/D58809

llvm-svn: 355217
llvm/lib/Transforms/Scalar/LICM.cpp
llvm/test/Transforms/LICM/promote-tls.ll
llvm/test/Transforms/LICM/scalar-promote-unwind.ll