summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-9/+19
| | | | | | | | | | | | | | | | | Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976
* Use llvm::stable_sortFangrui Song2019-04-241-2/+2
| | | | llvm-svn: 359098
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* Remove trailing spaceFangrui Song2018-07-301-9/+9
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [AST] Add a convenient getter from QualType to RecordDeclGeorge Karpenkov2018-07-281-3/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D49951 llvm-svn: 338187
* This patch provides that bitfields are splitted even in caseStrahinja Petrovic2018-05-101-10/+12
| | | | | | | | when current field is not legal integer type. Differential Revision: https://reviews.llvm.org/D39053 llvm-svn: 331979
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-11/+11
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [NFC] Fix terrible formatting of CGRecordLower constructor.Erich Keane2018-04-121-6/+7
| | | | llvm-svn: 329952
* Fix typos in clangAlexander Kornienko2018-04-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Add helper to determine if a field is a zero-length bitfield.Richard Smith2018-04-021-6/+5
| | | | llvm-svn: 328999
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-2/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [CodeGen] Fix an assertion failure in CGRecordLowering.Akira Hatanaka2018-02-011-2/+6
| | | | | | | | | | | | | | This patch fixes a bug in CGRecordLowering::accumulateBitFields where it unconditionally starts a new run and emits a storage field when it sees a zero-sized bitfield, which causes an assertion in insertPadding to fail when -fno-bitfield-type-align is used. It shouldn't emit new storage if UseZeroLengthBitfieldAlignment and UseBitFieldTypeAlignment are both false. rdar://problem/36762205 llvm-svn: 323943
* [Bitfield] Add an option to access bitfield in a fine-grained manner.Wei Mi2017-10-161-2/+35
| | | | | | | | Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default. Differential revision: https://reviews.llvm.org/D36562 llvm-svn: 315915
* 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
OpenPOWER on IntegriCloud