maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/2008-01-07-UnusualIntSize.c

17 lines
479 B
C
Raw Normal View History

clang/test/CodeGen/2008-01-07-UnusualIntSize.c: Add triple x86_64. It doesn't assume 32-bit target, for now. llvm-svn: 169492
2012-12-06 20:05:25 +08:00
// FIXME: 32-bit target?
// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -emit-llvm -o - | FileCheck %s
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
// PR1721
struct s {
unsigned long long u33: 33;
} a, b;
// This should have %0 and %1 truncated to 33 bits before any operation.
// This can be done using i33 or an explicit and.
_Bool test(void) {
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: and i64 %[[TMP1:[^,]+]], 8589934591
Attempt to rewrite the matching for this test to pacify the windows build bots. llvm-svn: 136166
2011-07-27 06:42:01 +08:00
// CHECK-NOT: and i64 [[TMP1]], 8589934591
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: and i64 %{{[^,]+}}, 8589934591
Migrate most of the rest of test/FrontendC from llvm and migrate most of them to FileCheck. llvm-svn: 136159
2011-07-27 06:17:02 +08:00
return a.u33 + b.u33 != 0;
}