llvm-project/clang/test/CodeGen/PR4611-bitfield-layout.c

// RUN: %clang_cc1 -triple i386-unknown-unknown %s -emit-llvm -o - | FileCheck %s
//
// CHECK: struct.object_entry = type { i32 }

struct object_entry {
       unsigned int type:3, pack_id:16, depth:13;
} entries;
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			`// RUN: %clang_cc1 -triple i386-unknown-unknown %s -emit-llvm -o - \| FileCheck %s`
			`//`
Complete Rewrite of CGRecordLayoutBuilder 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 llvm-svn: 201907 2014-02-22 07:49:50 +08:00			`// CHECK: struct.object_entry = type { i32 }`
Correct a thinko in bitfield layout code. Fixes PR4611. llvm-svn: 76898 2009-07-24 05:16:33 +08:00
			`struct object_entry {`
			`unsigned int type:3, pack_id:16, depth:13;`
			`} entries;`