http://llvm.org/bugs/show_bug.cgi?id=17815
Bug ID: 17815
Summary: Constant merging may illegally downgrade global
alignment
Product: libraries
Version: 3.2
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
Created attachment 11488
--> http://llvm.org/bugs/attachment.cgi?id=11488&action=edit
Patch to fix constmerge
The global constant merger and the instruction combining pass make
contradictory assumptions about the meaning of globals with zero (unspecified)
alignment.
Instcombine tries to upgrade the alignment on llvm.memcpy intrinsics. When
memcpy operates on a global without a defined alignment, using a stack like:
InstCombiner::SimplifyMemTransfer
llvm::getKnownAlignment
llvm::getOrEnforceKnownAlignment
llvm::ComputeMaskedBits
This latter uses TD->getPreferredAlignment if DataLayout is available; on
x86-64 this is 16 byte alignment.
By contrast, ConstMerge contains the line:
Replacements[i].second->setAlignment(std::max(
Replacements[i].first->getAlignment(),
Replacements[i].second->getAlignment()));
This assumes that zero alignment is exactly that -- no alignment at all.
ConstMerge also contains an unused, broken function ConstantMerge::getAlignment
that looks like it was trying to implement similar logic to ComputeMaskedBits.
My patch fixes it and uses it (I think it is ok that it remains simpler than
ComputeMaskedBits, which must deal with declarations, weak definitions and
other cases that cannot happen during constant merging).
I attach a test case in.ll which uses an unaligned memcpy against a global with
no declared alignment, but a duplicate constant exists with 8-byte alignment.
instcombine.ll illustrates the results of opt -instcombine: note the memcpy is
upgraded to assume 16-byte alignment, since the unaligned global will be
written with such (we think).
However, constmerge.ll shows what happens after a further opt -constmerge: the
two constants have merged, keeping the 8-byte alignment. Thus we have a
16-aligned memcpy against 8-aligned memory. If this particular test is compiled
we get away with it; however, inserting an extra rodata constant before .cst2
will cause synthesis of a misaligned x86 vector operation and consequent
segfault in the compiled program.
I will mention this report to llvm-commits per Chris Lattner's comment in bug
17757.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
