[LLVMbugs] [Bug 17815] New: Constant merging may illegally downgrade global alignment

[bugzilla-daemon at llvm.org]

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: unassignedbugs at nondot.org
          Reporter: chris at smowton.net
                CC: llvmbugs at cs.uiuc.edu
    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131105/d8cc2271/attachment.html>