Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322964 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253512 91177308-0d34-0410-b5e6-96231b3b80d8
* tbaa-struct.cpp always has a 64 bit pointer.
* f32:32:32, f64:64:64 and f128:128:128 are defaults, don't assume they are
printed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197415 91177308-0d34-0410-b5e6-96231b3b80d8
An updated version of r191586 with bug fix.
Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.
We should not generate a TBAA tag with null being the first field. When
a TBAA type node is null, the tag should be null too. Make sure we
don't decorate an instruction with a null TBAA tag.
Added a testing case for the bug reported by Richard with -relaxed-aliasing
and -fsanitizer=thread.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192145 91177308-0d34-0410-b5e6-96231b3b80d8
Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191586 91177308-0d34-0410-b5e6-96231b3b80d8
The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the underlying logic, and placed a burden on users of
the resulting RecordLayout. This commit rips out almost all of the
old code, and replaces it with simple checks in
RecordLayoutBuilder::LayoutBitField.
This commit also fixes <rdar://problem/14252115>, a bug where class
inheritance would cause us to lay out bitfields incorrectly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185018 91177308-0d34-0410-b5e6-96231b3b80d8
For ms structs, zero-length bitfields following non-bitfield members are
completely ignored, we should not increase the field index.
Before the fix, we will have an assertion failure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180038 91177308-0d34-0410-b5e6-96231b3b80d8
Ivan A. Kosarev