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

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Nov 5 06:01:38 PST 2013


            Bug ID: 17815
           Summary: Constant merging may illegally downgrade global
           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)

Instcombine tries to upgrade the alignment on llvm.memcpy intrinsics. When
memcpy operates on a global without a defined alignment, using a stack like:


This latter uses TD->getPreferredAlignment if DataLayout is available; on
x86-64 this is 16 byte alignment.

By contrast, ConstMerge contains the line:


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

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>

More information about the llvm-bugs mailing list