Automatic variable initialization was generating default-aligned stores (which are deprecated) instead of using the known alignment from the alloca.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/CGDecl.cpp | ||
---|---|---|
902 ↗ | (On Diff #155090) | llvm::Value::getPointerAlignment is not the right way to compute the alignment (it tries to guess the alignment based on the IR). Please convert this to use a clang::CodeGen::Address instead. |
I updated the patch to use Address, and also use inbounds. This was a bit tricky because of the GEPs. I also updated tests which run into this codegen. Only the following tests actually hit this code, and not all check these stores:
Clang :: CodeGen/2004-03-09-LargeArrayInitializers.c Clang :: CodeGen/indirect-goto.c Clang :: CodeGen/init.c Clang :: CodeGenCXX/float128-declarations.cpp Clang :: CodeGenObjC/messages-2.m Clang :: CodeGenObjC/messages.m Clang :: CodeGenOpenCL/address-space-constant-initializers.cl Clang :: CodeGenOpenCL/partial_initializer.cl Clang :: CodeGenOpenCL/private-array-initialization.cl
lib/CodeGen/CGBuilder.h | ||
---|---|---|
260 ↗ | (On Diff #155287) | It's close to doing what we want, but not quite? It seems like the original code would have used them otherwise. To use them we'd have to:
Seems simpler to use GEP2_32 and more fool-proof to (internal to the helper) use GEP's own idea of what the offset is, no? |
LGTM
lib/CodeGen/CGBuilder.h | ||
---|---|---|
260 ↗ | (On Diff #155287) | Okay. (Actually, I think this ends up conservatively underestimating the alignment in some cases involving nested structs, but it's unlikely to matter.) |