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
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201907 91177308-0d34-0410-b5e6-96231b3b80d8
My previous attempt was extremely deficient, allowing more volatiles
to be introduced and not even checking all of the ones that are
present.
This attempt doesn't try to keep track of the values stored or offsets
within particular objects, just that the correct objects are accessed
in a correctly volatile manner throughout.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174700 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64 handles aggFct's return struct slightly differently, leading
to an extra memcpy. This test is fortunately only concerned about
volatile copies, so we can modify the grep text to filter it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174621 91177308-0d34-0410-b5e6-96231b3b80d8
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108234 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86430 91177308-0d34-0410-b5e6-96231b3b80d8
value).
- Use extra argument to EmitStoreThroughLValue to provide place to
write update bit-field value if caller requires it.
- This fixes several FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59615 91177308-0d34-0410-b5e6-96231b3b80d8
qualifier in the lvalue, and changes lvalue loads/stores to honor
the volatile flag. Places which need some further attention are marked
with FIXMEs.
Patch by Cédric Venet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52264 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Neilson