Fix the root cause of PR15348 by correctly handling alignment 0 on
authorChandler Carruth <chandlerc@gmail.com>
Mon, 25 Feb 2013 14:20:21 +0000 (14:20 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Mon, 25 Feb 2013 14:20:21 +0000 (14:20 +0000)
commitaf23f8e403d68e3f96eb5eb63e50e3aec4ea01c9
tree6eb71c8e84ed3a57ae9901d1a123c8d6c98367ea
parentde89ecd011c453108c7641f44360f3a93af90206
Fix the root cause of PR15348 by correctly handling alignment 0 on
memory intrinsics in the SDAG builder.

When alignment is zero, the lang ref says that *no* alignment
assumptions can be made. This is the exact opposite of the internal API
contracts of the DAG where alignment 0 indicates that the alignment can
be made to be anything desired.

There is another, more explicit alignment that is better suited for the
role of "no alignment at all": an alignment of 1. Map the intrinsic
alignment to this early so that we don't end up generating aligned DAGs.

It is really terrifying that we've never seen this before, but we
suddenly started generating a large number of alignment 0 memcpys due to
the new code to do memcpy-based copying of POD class members. That patch
contains a bug that rounds bitfield alignments down when they are the
first field. This can in turn produce zero alignments.

This fixes weird crashes I've seen in library users of LLVM on 32-bit
hosts, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176022 91177308-0d34-0410-b5e6-96231b3b80d8
lib/CodeGen/SelectionDAG/SelectionDAG.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
test/CodeGen/X86/memcpy.ll
test/CodeGen/X86/memset.ll