summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-2/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+2
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-2/+2
| | | | | | r259192 post commit comment. llvm-svn: 259232
* Update for LLVM function name change.Rui Ueyama2016-01-141-4/+4
| | | | llvm-svn: 257802
* [MS ABI] Don't crash when inheriting from base with trailing empty array memberDavid Majnemer2015-10-221-1/+1
| | | | | | | | | | We got this right for Itanium but not MSVC because CGRecordLayoutBuilder was checking if the base's size was zero when it should have been checking the non-virtual size. This fixes PR21040. llvm-svn: 251036
* Respect alignment of nested bitfieldsUlrich Weigand2015-07-101-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* [CodeGen] Indirect fields can initialize a unionDavid Majnemer2015-05-301-3/+7
| | | | | | | | The first named data member is the field used to default initialize the union. An IndirectFieldDecl can introduce the first named data member of a union. llvm-svn: 238649
* [CodeGen] Handle flexible array members containing pointers to membersDavid Majnemer2015-05-261-7/+2
| | | | | | | | | | Types can be classified as being zero-initializable or non-zero-initializable. We used to classify array types by giving them the classification of their base element type. However, incomplete array types are never initialized directly and thus are always zero-initializable. llvm-svn: 238256
* ms_struct does not imply the MS base-layout ABI; separate theseJohn McCall2015-04-281-6/+23
| | | | | | | | conditions in the IRGen struct layout code. rdar://20636558 llvm-svn: 235949
* Correctly handle zero-sized but non-empty base classes in IRGen.John McCall2015-04-261-1/+5
| | | | | | | | | | | | | | | | Fixes rdar://20621065. A more elegant fix would preclude this case by defining the rules such that zero-size classes are always formally empty. I believe the only extensions which create zero-size classes right now are flexible arrays and zero-length arrays; it's not abstractly unreasonable to say that those don't count as members for the purposes of emptiness, just as zero-width bitfields don't count. But that's an ABI-affecting change and requires further discussion; in the meantime, let's not assert / miscompile. llvm-svn: 235815
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-151-2/+2
| | | | | | requiring the macro. NFC; Clang edition. llvm-svn: 229339
* CodeGen: Cleanup CGRecordLowering::lowerUnion a littleDavid Majnemer2014-10-151-7/+7
| | | | | | Remove some duplicated state, no functionality change intended. llvm-svn: 219805
* CodeGen: Use the initing member's type for a union's storage type more oftenDavid Majnemer2014-10-151-1/+16
| | | | | | | | | | Unions are initialized with the default initialization of their first named member. If that member is not zero initialized, then we should prefer that member's type. Otherwise, we might try to make an otherwise unsuitable type (like an array) which we cannot easily initialize with a pointer to member. llvm-svn: 219781
* CodeGen: Fix a typo in a commentDavid Majnemer2014-10-151-1/+1
| | | | | | No functionality change intended. llvm-svn: 219780
* CodeGen: Don't crash when initializing pointer-to-member fields in basesDavid Majnemer2014-09-281-10/+26
| | | | | | | | | | | | | | | | | Clang uses two types to talk about a C++ class, the NonVirtualBaseLLVMType and the LLVMType. Previously, we would allow one of these to be packed and the other not. This is problematic. If both don't agree on a common subset of fields, then routines like getLLVMFieldNo will point to the wrong field. Solve this by copying the 'packed'-ness of the complete type to the non-virtual subobject. For this to work, we need to take into account the non-virtual subobject's size and alignment when we are computing the layout of the complete object. This fixes PR21089. llvm-svn: 218577
* Revert "CodeGen: When bitfields fall on natural boundaries, split them up"Justin Bogner2014-08-141-9/+2
| | | | | | | | | | | | | | | It fits better with LLVM's memory model to try to do this in the backend. Specifically, narrowing wide loads in the backends should be relatively straightforward and is generally valuable, whereas widening loads tends to be very constrained. Discussion here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140811/112581.html This reverts commit r215614. llvm-svn: 215648
* CodeGen: When bitfields fall on natural boundaries, split them upJustin Bogner2014-08-141-2/+9
| | | | | | | | | | | | | | | | | | | Currently when laying out bitfields that don't need any padding, we represent them as a wide enough int to contain all of the bits. This can be hard on the backend since we'll do things like represent stores to a few bits as loading an i144, masking it with a large constant, and storing it back. This turns up in less pathological cases where we load and mask 64 bit word on a 32 bit platform when we actually only need to access 32 bits. This leads to bad code being generated in most of our 32 bit backends. In practice, there are often natural breaks in bitfields, and it's a fairly simple and effective heuristic to split these fields into legal integer sized chunks when it will be equivalent (ie, it won't force us to add any extra padding). llvm-svn: 215614
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-7/+9
| | | | llvm-svn: 209272
* Fixed Assert In CGRecordLoweringWarren Hunt2014-04-251-6/+23
| | | | | | | | | | | Prior to this patch, CGRecordLower assumed that virtual bases could not be placed before the nvsize of an object. This isn't true in Itanium mode, virtual bases are placed at dsize rather than vnsize and in the case of zero sized non-virtual bases nvsize can be larger than dsize. This patch fixes CGRecordLowering to avoid an assert and to clip bitfields properly in this case. A test case is included. llvm-svn: 207280
* When a module completes the definition of a class template specialization ↵Richard Smith2014-04-191-3/+3
| | | | | | imported from another module, emit an update record, rather than using the broken decl rewriting mechanism. If multiple modules do this, merge the definitions together, much as we would if they were separate declarations. llvm-svn: 206680
* [C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() ↵Aaron Ballman2014-03-131-4/+2
| | | | | | with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
* [C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with ↵Aaron Ballman2014-03-131-9/+5
| | | | | | iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-7/+5
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Fixed an assertion failure related to bitfield lowering.Warren Hunt2014-03-011-2/+5
| | | | | | | | | When lowering a bitfield, CGRecordLowering would assign the wrong storage type to a bitfield in some cases and trigger an assertion. In these cases the layout was still correct, just the bitfield info was wrong. llvm-svn: 202562
* PR18962: Fix "Unable to find record layout information for type"Reid Kleckner2014-02-271-2/+5
| | | | | | | | | | | | | | | | | | | Clang is using llvm::StructType::isOpaque() as a way of signaling if we've finished record type conversion in CodeGenTypes::isRecordLayoutComplete(). However, Clang was setting the body of the type before it finished laying out the type as a base type. Laying out the %class.C.base LLVM type attempts to convert more types, eventually recursively attempting to layout 'C' again, at which point we would say that layout was complete, even though we were still in the middle of it. By not setting the body, we correctly signal that layout is not complete, and things work as expected. At some point, it might be worth refactoring this to avoid looking at the LLVM IR types under construction. llvm-svn: 202320
* IRGen: Simplify alignment calculation in setBitFieldInfoDavid Majnemer2014-02-251-4/+2
| | | | | | | | | Take advantage of CharUnits::alignmentAtOffset instead of calculating it by hand. Differential Revision: http://llvm-reviews.chandlerc.com/D2862 llvm-svn: 202098
* IRGen: Fix build breakageDavid Majnemer2014-02-221-1/+1
| | | | | | | MSVC allows extra-qualification on member functions, it lets you repeat the class name on the method. llvm-svn: 201918
* Fix two warnings introduced r201907Warren Hunt2014-02-221-5/+4
| | | | | | | Unused variable is removed. Construction order is changed to match declaration order. llvm-svn: 201914
* Complete Rewrite of CGRecordLayoutBuilderWarren Hunt2014-02-211-946/+545
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fixing PR18430 by checking that the size of bitfields plus padding does notYunzhong Gao2014-01-291-1/+6
| | | | | | | | grow into the following virtual base. Differential Revision: http://llvm-reviews.chandlerc.com/D2560 llvm-svn: 200359
* Fixing PR18510 by checking whether the non-virtual base of the derived classYunzhong Gao2014-01-241-1/+6
| | | | | | | | | | might have a smaller size as compared to the stand-alone type of the base class. This is possible when the derived class is packed and hence might have smaller alignment requirement than the base class. Differential Revision: http://llvm-reviews.chandlerc.com/D2599 llvm-svn: 200031
* CGRecordLayoutBuilder.cpp: Clarify if-else. [-Wdangling-else]NAKAMURA Takumi2014-01-101-1/+2
| | | | llvm-svn: 198906
* [ms-abi] Fixing CGRecordLayoutBuilder w.r.t. MS NonVirutalBase LayoutWarren Hunt2014-01-091-1/+75
| | | | | | | | | | | | | | The MS abi lays out *all* non-virtual bases with leading vfptrs before laying out non-virutal bases without vfptrs. This guarantees that the primary base is laid out first. r198818 fixed RecordLayoutBuilder to produce compatiable layouts. This patch fixes CGRecordLayoutBuilder to be able to consume those layouts and produce meaningful output without tripping any asserts about assumed incoming layout. A test case is included that shows CGRecordLayoutBuilder in fact produces output in the compatiable order. llvm-svn: 198900
* [ms-abi] Refactor Microsoft Record LayoutWarren Hunt2014-01-091-2/+2
| | | | | | | | | This patch refactors microsoft record layout to be more "natural". The most dominant change is that vbptrs and vfptrs are injected after the fact. This simplifies the implementation and the math for the offest for the first base/field after the vbptr. llvm-svn: 198818
* Fix a tranche of comment, test and doc typosAlp Toker2013-12-051-1/+1
| | | | llvm-svn: 196510
* Fix typo in CGRecordLayoutBuilder.cpp: s/Field/Fields/ in commentHans Wennborg2013-11-151-1/+1
| | | | llvm-svn: 194863
* Minor efficiency refactor related to 193661. No functional change.Warren Hunt2013-10-301-4/+2
| | | | llvm-svn: 193665
* Fixing code gen to handle microsoft layouts for which size % alignment Warren Hunt2013-10-291-0/+3
| | | | | | != 0 llvm-svn: 193661
* Adds Microsoft compatiable C++ record layout code to clang.Warren Hunt2013-10-111-1/+1
| | | | llvm-svn: 192494
* Changes so that a few tests do not fail when running under guarded malloc.Argyrios Kyrtzidis2013-07-121-5/+5
| | | | | | | Guarded malloc emits some messages at the beginning in stderr when enabled. These messages caused a few tests to fail. llvm-svn: 186219
* Rewrite record layout for ms_struct structs.Eli Friedman2013-06-261-33/+2
| | | | | | | | | | | | | | The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
* Standardize accesses to the TargetInfo in IR-gen.John McCall2013-04-161-4/+4
| | | | | | Patch by Stephen Lin! llvm-svn: 179638
* First pass at abstracting out a class for the target C++ ABI.John McCall2013-01-251-1/+1
| | | | llvm-svn: 173514
* Fix signed/unsigned CompareDavid Greene2013-01-151-1/+2
| | | | | | Do some casting to avoid a signed/unsigned compare. llvm-svn: 172571
* Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate toChandler Carruth2013-01-021-3/+3
| | | | | | | | reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
* Fix a compilation warning with gcc 4.6Eli Bendersky2012-12-181-1/+1
| | | | llvm-svn: 170440
* Cleanup and fix an assert that was mis-firing.Chandler Carruth2012-12-091-5/+13
| | | | | | | | | | | | | | | | Note that there is no test suite update. This was found by a couple of tests failing when the test suite was run on a powerpc64 host (thanks Roman!). The tests don't specify a triple, which might seem surprising for a codegen test. But in fact, these tests don't even inspect their output. Not at all. I could add a bunch of triples to these tests so that we'd get the test coverage for normal builds, but really someone needs to go through and add actual *tests* to these tests. =[ The ones in question are: test/CodeGen/bitfield-init.c test/CodeGen/union.c llvm-svn: 169694
* Fix the bitfield record layout in codegen for big endian targets.Chandler Carruth2012-12-091-3/+7
| | | | | | | | | | | | | | | | | | This was an egregious bug due to the several iterations of refactorings that took place. Size no longer meant what it original did by the time I finished, but this line of code never got updated. Unfortunately we had essentially zero tests for this in the regression test suite. =[ I've added a PPC64 run over the bitfield test case I've been primarily using. I'm still looking at adding more tests and making sure this is the *correct* bitfield access code on PPC64 linux, but it looks pretty close to me, and it is *worlds* better than before this patch as it no longer asserts! =] More commits to follow with at least additional tests and maybe more fixes. Sorry for the long breakage due to this.... llvm-svn: 169691
OpenPOWER on IntegriCloud