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/bitfield-access.m

43 lines
1.2 KiB
Mathematica
Raw Normal View History

Restructure how the driver communicates information about the target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
2012-06-20 14:18:46 +08:00
// RUN: %clang_cc1 -triple i386-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 -emit-llvm -o %t1 %s
tests: Tweak test to not write to the same temporary twice, in the hopes of avoiding sporadic win32 failures about renaming a temporary. llvm-svn: 130439
2011-04-29 05:23:38 +08:00
// RUN: FileCheck -check-prefix=CHECK-I386 < %t1 %s
Restructure how the driver communicates information about the target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
2012-06-20 14:18:46 +08:00
// RUN: %clang_cc1 -triple armv6-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 -target-abi apcs-gnu -emit-llvm -o %t2 %s
tests: Tweak test to not write to the same temporary twice, in the hopes of avoiding sporadic win32 failures about renaming a temporary. llvm-svn: 130439
2011-04-29 05:23:38 +08:00
// RUN: FileCheck -check-prefix=CHECK-ARM < %t2 %s
IRgen/Obj-C: Rewrite Objective-C bit-field access to compute the access strategy using the same methods as used for normal structures. - This fixes problems with reading past the end of the structure and with handling straddled bit-field access. llvm-svn: 112914
2010-09-03 07:53:31 +08:00
@interface I0 {
@public
unsigned x:15;
unsigned y: 1;
}
@end
// Check that we don't try to use an i32 load here, which would reach beyond the
// end of the structure.
//
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-I386-LABEL: define i32 @f0(
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK-I386: [[t0_0:%.*]] = load i8, i8* {{.*}}, align 1
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// CHECK-I386: lshr i8 [[t0_0]], 7
IRgen/Obj-C: Rewrite Objective-C bit-field access to compute the access strategy using the same methods as used for normal structures. - This fixes problems with reading past the end of the structure and with handling straddled bit-field access. llvm-svn: 112914
2010-09-03 07:53:31 +08:00
// CHECK-I386: }
int f0(I0 *a) {
return a->y;
}
// Check that we can handled straddled loads.
//
CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail. llvm-svn: 188447
2013-08-15 14:47:53 +08:00
// CHECK-ARM-LABEL: define i32 @f1(
IRgen/Obj-C: Rewrite Objective-C bit-field access to compute the access strategy using the same methods as used for normal structures. - This fixes problems with reading past the end of the structure and with handling straddled bit-field access. llvm-svn: 112914
2010-09-03 07:53:31 +08:00
// CHECK-ARM: [[t1_ptr:%.*]] = getelementptr
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// CHECK-ARM: [[t1_base:%.*]] = bitcast i8* [[t1_ptr]] to i40*
Update Clang tests to handle explicitly typed load changes in LLVM. llvm-svn: 230795
2015-02-28 05:19:58 +08:00
// CHECK-ARM: [[t1_0:%.*]] = load i40, i40* [[t1_base]], align 1
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// CHECK-ARM: [[t1_1:%.*]] = lshr i40 [[t1_0]], 1
// CHECK-ARM: [[t1_2:%.*]] = and i40 [[t1_1]],
// CHECK-ARM: trunc i40 [[t1_2]] to i32
IRgen/Obj-C: Rewrite Objective-C bit-field access to compute the access strategy using the same methods as used for normal structures. - This fixes problems with reading past the end of the structure and with handling straddled bit-field access. llvm-svn: 112914
2010-09-03 07:53:31 +08:00
// CHECK-ARM: }
@interface I1 {
@public
unsigned x: 1;
unsigned y:32;
}
@end
int f1(I1 *a) { return a->y; }