summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/bitfield-2.c
Commit message (Collapse)AuthorAgeFilesLines
* C11 _Bool bitfield diagnosticRachel Craik2015-09-141-1/+1
| | | | | | | | | | | | Summary: Implement DR262 (for C). This patch will mainly affect bitfields of type _Bool Reviewers: fraggamuffin, rsmith Subscribers: hubert.reinterpretcast, cfe-commits Differential Revision: http://reviews.llvm.org/D10018 llvm-svn: 247618
* Respect alignment of nested bitfieldsUlrich Weigand2015-07-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test: struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YBitfield { char x; struct XBitfield y; } __attribute((packed)); struct YBitfield gbitfield; unsigned test7() { // CHECK: @test7 // CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4 return gbitfield.y.b2; } The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single i32 is of course possible, but that still doesn't make it 4-byte aligned as it remains packed at offset 1 in the surrounding gbitfield object. This alignment was changed by commit r169489, which also introduced changes to bitfield access code in CGExpr.cpp. Code before that change used to take into account *both* the alignment of the field to be accessed within the current struct, *and* the alignment of that outer struct itself; this logic was removed by the above commit. Neglecting to consider both values can cause incorrect code to be generated (I've seen an unaligned access crash on SystemZ due to this bug). In order to always use the best known alignment value, this patch removes the CGBitFieldInfo::StorageAlignment member and replaces it with a StorageOffset member specifying the offset from the start of the surrounding struct to the bitfield's underlying storage. This offset can then be combined with the best-known alignment for a bitfield access lvalue to determine the alignment to use when accessing the bitfield's storage. Differential Revision: http://reviews.llvm.org/D11034 llvm-svn: 241916
* Complete Rewrite of CGRecordLayoutBuilderWarren Hunt2014-02-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* CHECK-LABEL-ify some code gen tests to improve diagnostic experience when ↵Stephen Lin2013-08-151-8/+8
| | | | | | tests fail. llvm-svn: 188447
* Changes so that a few tests do not fail when running under guarded malloc.Argyrios Kyrtzidis2013-07-121-1/+1
| | | | | | | Guarded malloc emits some messages at the beginning in stderr when enabled. These messages caused a few tests to fail. llvm-svn: 186219
* Add indents to AST dumping and removed parenthesis from AST nodes.Richard Trieu2013-01-311-4/+4
| | | | | | | | | | | | | | | | | | | | | Indents were given the color blue when outputting with color. AST dumping now looks like this: Node |-Node | `-Node `-Node `-Node Compared to the previous: (Node (Node (Node)) (Node (Node))) llvm-svn: 174022
* Implement AST dumper for Decls.Alexander Kornienko2012-12-201-4/+4
| | | | | | | | http://llvm-reviews.chandlerc.com/D52 Patch by Philip Craig! llvm-svn: 170634
* Rework the bitfield access IR generation to address PR13619 andChandler Carruth2012-12-061-31/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang side to match the LLVM IR type system rewrite patch.Chris Lattner2011-07-091-4/+4
| | | | llvm-svn: 134831
* Go back to asking CodeGenTypes whether a type is zero-initializable.John McCall2010-08-221-4/+4
| | | | | | | | | Make CGT defer to the ABI on all member pointer types. This requires giving CGT a handle to the ABI. It's way easier to make that work if we avoid lazily creating the ABI. Make it so. llvm-svn: 111786
* IRgen: Fix another case where we generated an invalid access component when weDaniel Dunbar2010-04-221-0/+21
| | | | | | | immediately narrowed the access size. Fix this (and previous case) by just choosing a better access size up-front. llvm-svn: 102068
* IRgen: Fix case where we might generate an access component with width == 0, ifDaniel Dunbar2010-04-221-0/+35
| | | | | | | we have to narrow the access side immediately (can happen with packed, -fno-bitfield-type-align). llvm-svn: 102067
* IRgen: Set alignment correctly on bit-field accesses.Daniel Dunbar2010-04-221-6/+36
| | | | llvm-svn: 102046
* IRgen: Rewrite bit-field access policy to not access data beyond the bounds ↵Daniel Dunbar2010-04-221-3/+49
| | | | | | | | | | | | of the structure, which we also now verify as part of the post-layout consistency checks. - This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align. - Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues. - Review appreciated. llvm-svn: 102045
* IRgen: Always use i8 arrays to access union bit-fields. This is ugly, butDaniel Dunbar2010-04-201-10/+23
| | | | | | | matches how we currently handle structs, and this correctly handles -fno-bitfield-type-align. llvm-svn: 101918
* Fix an assert when assigning a boolean value to a bitfield of type _Bool.Anders Carlsson2010-04-171-0/+16
| | | | llvm-svn: 101678
* IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to ↵Daniel Dunbar2010-04-151-0/+207
| | | | | | | | | | | | | | | | use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job. - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit. The new fixes from r101222 are: 1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt. 2. Swap the order of arguments to OR, to get a tad more constant folding. llvm-svn: 101339
* Speculatively revert "IRgen: Move EmitStoreThroughBitfieldLValue to use new ↵Daniel Dunbar2010-04-141-176/+0
| | | | | | CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.", I think it might be breaking bootstrap. llvm-svn: 101235
* IRgen: Move EmitStoreThroughBitfieldLValue to use new ↵Daniel Dunbar2010-04-141-0/+176
CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job. - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit. llvm-svn: 101222
OpenPOWER on IntegriCloud