maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenObjC/stret-1.m

33 lines
1.3 KiB
Mathematica
Raw Normal View History

Don't nil check non-nil class receiver of AArch64 stret calls. I randomly came across this difference between AArch64 and other targets: on the latter, we don't emit nil checks for known non-nil class method calls thanks to r247350, but we still do for AArch64 stret calls. They use different code paths, because those are special, as they go through the regular msgSend, not the msgSend*_stret variants. llvm-svn: 249205
2015-10-03 06:41:59 +08:00
// RUN: %clang_cc1 -fblocks -triple arm64-apple-darwin %s -emit-llvm -o - | FileCheck %s
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
// rdar://12416433
struct stret { int x[100]; };
struct stret one = {{1}};
@interface Test @end
@implementation Test
+(struct stret) method { return one; }
@end
int main(int argc, const char **argv)
{
[objc] Don't require null-check and don't emit memset when result is ignored for struct-returning method calls [clang part] This fixes an issue with the emission of lifetime markers for struct-returning Obj-C msgSend calls. When the result of a struct-returning call is ignored, the temporary storage is only marked with lifetime markers in one of the two branches of the nil-receiver-check. The check is, however, not required when the result is unused. If we still need to emit the check (due to consumer arguments), let's not emit the memset to zero out the result if it's unused. This fixes a use-after-scope false positive with AddressSanitizer. Differential Revision: https://reviews.llvm.org/D34834 llvm-svn: 306837
2017-07-01 00:28:15 +08:00
struct stret s;
s = [(id)(argc&~255) method];
Don't nil check non-nil class receiver of AArch64 stret calls. I randomly came across this difference between AArch64 and other targets: on the latter, we don't emit nil checks for known non-nil class method calls thanks to r247350, but we still do for AArch64 stret calls. They use different code paths, because those are special, as they go through the regular msgSend, not the msgSend*_stret variants. llvm-svn: 249205
2015-10-03 06:41:59 +08:00
// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void (%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T0:%[^,]+]]
// CHECK: [[T0P:%.*]] = bitcast %struct.stret* [[T0]] to i8*
Change memcpy/memove/memset to have dest and source alignment attributes (Step 1). 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. llvm-svn: 322964
2018-01-20 01:12:54 +08:00
// CHECK: call void @llvm.memset.p0i8.i64(i8* align 4 [[T0P]], i8 0, i64 400, i1 false)
ARM64: initial clang support commit. This adds Clang support for the ARM64 backend. There are definitely still some rough edges, so please bring up any issues you see with this patch. As with the LLVM commit though, we think it'll be more useful for merging with AArch64 from within the tree. llvm-svn: 205100
2014-03-29 23:09:45 +08:00
[objc] Don't require null-check and don't emit memset when result is ignored for struct-returning method calls [clang part] This fixes an issue with the emission of lifetime markers for struct-returning Obj-C msgSend calls. When the result of a struct-returning call is ignored, the temporary storage is only marked with lifetime markers in one of the two branches of the nil-receiver-check. The check is, however, not required when the result is unused. If we still need to emit the check (due to consumer arguments), let's not emit the memset to zero out the result if it's unused. This fixes a use-after-scope false positive with AddressSanitizer. Differential Revision: https://reviews.llvm.org/D34834 llvm-svn: 306837
2017-07-01 00:28:15 +08:00
s = [Test method];
// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void (%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T1:%[^,]+]]
// CHECK-NOT: call void @llvm.memset.p0i8.i64(
[(id)(argc&~255) method];
// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void (%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T1:%[^,]+]]
// CHECK-NOT: call void @llvm.memset.p0i8.i64(
Don't nil check non-nil class receiver of AArch64 stret calls. I randomly came across this difference between AArch64 and other targets: on the latter, we don't emit nil checks for known non-nil class method calls thanks to r247350, but we still do for AArch64 stret calls. They use different code paths, because those are special, as they go through the regular msgSend, not the msgSend*_stret variants. llvm-svn: 249205
2015-10-03 06:41:59 +08:00
[Test method];
// CHECK: call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void (%struct.stret*, i8*, i8*)*)(%struct.stret* sret [[T1:%[^,]+]]
// CHECK-NOT: call void @llvm.memset.p0i8.i64(
}