summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGClass.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert r326946. It caused stack overflows by significantly increasing the ↵Richard Smith2018-03-101-4/+4
| | | | | | size of a CallArgList. llvm-svn: 327195
* CodeGen: Fix address space of indirect function argumentYaxun Liu2018-03-071-4/+4
| | | | | | | | | | | | | | | | | | | | | The indirect function argument is in alloca address space in LLVM IR. However, during Clang codegen for C++, the address space of indirect function argument should match its address space in the source code, i.e., default addr space, even for indirect argument. This is because destructor of the indirect argument may be called in the caller function, and address of the indirect argument may be taken, in either case the indirect function argument is expected to be in default addr space, not the alloca address space. Therefore, the indirect function argument should be mapped to the temp var casted to default address space. The caller will cast it to alloca addr space when passing it to the callee. In the callee, the argument is also casted to the default address space and used. CallArg is refactored to facilitate this fix. Differential Revision: https://reviews.llvm.org/D34367 llvm-svn: 326946
* [CodeGen] Use the non-virtual alignment when emitting the baseAkira Hatanaka2018-01-271-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructor. Previously, clang would emit an over-aligned (16-byte) store to initialize B::x in B's base constructor when compiling the following code: struct A { __attribute__((aligned(16))) double data1; }; struct B : public virtual A { B() : x(123) {} double a; int x; }; struct C : public virtual B {}; void test() { B b; C c; } This was happening because the code in IRGen that does member initialization was using the alignment of a complete object instead of the non-virtual alignment. This commit fixes the bug. rdar://problem/36382481 Differential Revision: https://reviews.llvm.org/D42521 llvm-svn: 323578
* [CodeGen] Decorate aggregate accesses with TBAA tagsIvan A. Kosarev2018-01-251-6/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D41539 llvm-svn: 323421
* [CodeGenCXX] annotate a GEP to a derived class with 'inbounds' (PR35909)Sanjay Patel2018-01-191-2/+2
| | | | | | | | | | | | | | | | The standard says: [expr.static.cast] p11: "If the prvalue of type “pointer to cv1 B” points to a B that is actually a subobject of an object of type D, the resulting pointer points to the enclosing object of type D. Otherwise, the behavior is undefined." Therefore, the GEP must be inbounds. This should solve the failure to optimize away a null check shown in PR35909: https://bugs.llvm.org/show_bug.cgi?id=35909 Differential Revision: https://reviews.llvm.org/D42249 llvm-svn: 322950
* In an ARC lambda-to-block conversion thunk, reclaim the return value ofJohn McCall2017-12-141-2/+5
| | | | | | | | the lambda so that we don't over-release it. Patch by Dan Zimmerman! llvm-svn: 320721
* IRGen: When performing CFI checks, load vtable pointer from vbase when ↵Peter Collingbourne2017-12-131-2/+3
| | | | | | | | | | | | | | necessary. Under the Microsoft ABI, it is possible for an object not to have a virtual table pointer of its own if all of its virtual functions were introduced by virtual bases. In that case, we need to load the vtable pointer from one of the virtual bases and perform the type check using its type. Differential Revision: https://reviews.llvm.org/D41036 llvm-svn: 320638
* [CodeGen] Collect information about sizes of accesses and access types for TBAAIvan A. Kosarev2017-11-271-2/+4
| | | | | | | | | | | | | | The information about access and type sizes is necessary for producing TBAA metadata in the new size-aware format. With this patch, D39955 and D39956 in place we should be able to change CodeGenTBAA::createScalarTypeNode() and CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new format under the -new-struct-path-tbaa command-line option. For now, this new information remains unused. Differential Revision: https://reviews.llvm.org/D40176 llvm-svn: 319012
* [CodeGen] getNaturalTypeAlignment() to generate TBAA info along with LValue ↵Ivan A. Kosarev2017-10-131-3/+2
| | | | | | | | | | base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38794 llvm-svn: 315708
* [CodeGen] EmitCXXMemberDataPointerAddress() to generate TBAA info along with ↵Ivan A. Kosarev2017-10-131-1/+4
| | | | | | | | | | LValue base info This patch should not bring in any functional changes. Differential Revision: https://reviews.llvm.org/D38788 llvm-svn: 315702
* Fix an unused-variable warning.Haojian Wu2017-10-131-1/+1
| | | | llvm-svn: 315689
* Support for destroying operator delete, per C++2a proposal P0722.Richard Smith2017-10-131-22/+60
| | | | | | | | | | This feature is not (yet) approved by the C++ committee, so this is liable to be reverted or significantly modified based on committee feedback. No functionality change intended for existing code (a new type must be defined in namespace std to take advantage of this feature). llvm-svn: 315662
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314979
* Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"Ivan A. Kosarev2017-10-051-2/+2
| | | | | | | | D37826 has been mistakenly committed where it should be the patch from D38503. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314978
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314977
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-251-24/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* [MSan] Disable sanitization for __sanitizer_dtor_callback.Matt Morehouse2017-09-201-0/+1
| | | | | | | | | | | | | | | | Summary: Eliminate unnecessary instrumentation at __sanitizer_dtor_callback call sites. Fixes https://github.com/google/sanitizers/issues/861. Reviewers: eugenis, kcc Reviewed By: eugenis Subscribers: vitalybuka, llvm-commits, cfe-commits, hiraditya Differential Revision: https://reviews.llvm.org/D38063 llvm-svn: 313831
* Clean up some lambda conversion operator code, NFCReid Kleckner2017-08-041-13/+11
| | | | | | | | | | | | | | We don't need special handling in CodeGenFunction::GenerateCode for lambda block pointer conversion operators anymore. The conversion operator emission code immediately calls back to the generic EmitFunctionBody. Rename EmitLambdaStaticInvokeFunction to EmitLambdaStaticInvokeBody for better consistency with the other Emit*Body methods. I'm preparing to do something about PR28299, which touches this code. llvm-svn: 310145
* Re-apply r309622 with a fix for MSVC.Peter Collingbourne2017-07-311-5/+4
| | | | | | Patch by Vlad Tsyrklevich! llvm-svn: 309635
* Revert r309622, "Fix logic for generating llvm.type.test()s"Peter Collingbourne2017-07-311-4/+5
| | | | | | | Caused a bot test failure: http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/5325 llvm-svn: 309624
* Fix logic for generating llvm.type.test()sPeter Collingbourne2017-07-311-5/+4
| | | | | | | | | | | | | | CodeGenFunction::EmitTypeMetadataCodeForVCall() could output an llvm.assume(llvm.type.test())when CFI was enabled, optimizing out the vcall check. This case was only reached when: 1) CFI-vcall was enabled, 2) -fwhole-program-tables was specified, and 3) -fno-sanitize-trap=cfi-vcall was specified. Patch by Vlad Tsyrklevich! Differential Revision: https://reviews.llvm.org/D36013 llvm-svn: 309622
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-131-82/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* Prevent devirtualization of calls to un-instantiated functions.Sunil Srivastava2017-06-201-2/+11
| | | | | | | | PR 27895 Differential Revision: https://reviews.llvm.org/D22057 llvm-svn: 305862
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-2/+2
| | | | | | | | | | | | | The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. This patch should not introduce any functional changes. Differential Revision: https://reviews.llvm.org/D33284 llvm-svn: 303358
* PR32042: Create inlined debug info for EmitInlinedInheritingCXXConstructorCall.Adrian Prantl2017-02-271-1/+3
| | | | | | | | | | | | | | | | | | When clang emits an inheriting C++ constructor it may inline code during the CodeGen phase. This patch ensures that any debug info in this inlined code gets a proper inlined location. Otherwise we can end up with invalid debug info metadata, since all inlined local variables and function arguments would be reparented into the call site. Analogous to ApplyInlineLocation this patch introduces a ApplyInlineDebugLocation scoped helper to facilitate entering an inlined scope and cleaning up afterwards. This fixes one of the issues discovered in PR32042. rdar://problem/30679307 llvm-svn: 296388
* C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules ↵Richard Smith2017-02-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
* [profiling] PR31992: Don't skip interesting non-base constructorsVedant Kumar2017-02-241-1/+2
| | | | | | | | | Fix the fact that we don't assign profile counters to constructors in classes with virtual bases, or constructors with variadic parameters. Differential Revision: https://reviews.llvm.org/D30131 llvm-svn: 296062
* [CodeGen] Fix ExtParameterInfo bugs in C++ CodeGen code.George Burgess IV2017-02-231-4/+5
| | | | | | | | | | | | | | | | This patch makes use of the prefix/suffix ABI argument distinction that was introduced in r295870, so that we now emit ExtParameterInfo at the correct offset for member calls that have added ABI arguments. I don't see a good way to test the generated param info, since we don't actually seem to use it in CGFunctionInfo outside of Swift. Any suggestions/thoughts for how to better test this are welcome. :) This patch also fixes a small bug with inheriting constructors: if we decide not to pass args into an base class ctor, we would still generate ExtParameterInfo as though we did. The added test-case is for that behavior. llvm-svn: 296024
* [CodeGen] Note where we add ABI-specific args in ctors. NFC.George Burgess IV2017-02-221-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Meta: The ultimate goal is to teach ExtParameterInfo about pass_object_size attributes. This is necessary for that, since our ExtParameterInfo is a bit buggy in C++. I plan to actually make use of this Prefix/Suffix info in the near future, but I like small single-purpose changes. Especially when those changes are hard to actually test... At the moment, some of our C++-specific CodeGen pretends that ABIs can only add arguments to the beginning of a function call. This isn't quite correct: args can be appended to the end, as well. It hasn't mattered much until now, since we seem to only use this "number of arguments added" data when calculating the ExtParameterInfo to use when making a CGFunctionInfo. Said ExtParameterInfo is currently only used for ParameterABIs (Swift) and ns_consumed (ObjC). So, this patch allows ABIs to indicate whether args they added were at the beginning or end of an argument list. We can use this information to emit ExtParameterInfos more correctly, though like said, that bit is coming soon. No tests since this is theoretically a nop. llvm-svn: 295870
* [ubsan] Pass a set of checks to skip to EmitTypeCheck() (NFC)Vedant Kumar2017-02-171-2/+6
| | | | | | | | | | | CodeGenFunction::EmitTypeCheck accepts a bool flag which controls whether or not null checks are emitted. Make this a bit more flexible by changing the bool to a SanitizerSet. Needed for an upcoming change which deals with a scenario in which we only want to emit null checks. llvm-svn: 295514
* Prevent ICE in dllexport class with _Atomic data memberWarren Ristow2017-02-021-4/+5
| | | | | | | | | | Guard against a null pointer dereference that caused Clang to crash when processing a class containing an _Atomic qualified data member, and that is tagged with 'dllexport'. Differential Revision: https://reviews.llvm.org/D29208 llvm-svn: 293911
* CodeGen: add a LLVM_FALLTHROUGH to a fallthrough (NFC)Saleem Abdulrasool2017-02-021-3/+3
| | | | | | Drive by cleanup noticed while investigating an IR verifier assertion. llvm-svn: 293867
* clang-cl: Evaluate arguments left-to-right in constructor call with ↵Hans Wennborg2017-02-011-1/+5
| | | | | | | | | | | | initializer list (PR31831) clang-cl would evaluate the arguments right-to-left (see PR), and for non-Windows targets I suppose we only got it because we were already emitting left-to-right in CodeGenFunction::EmitCallArgs. Differential Revision: https://reviews.llvm.org/D29350 llvm-svn: 293732
* Remove custom handling of array copies in lambda by-value array capture andRichard Smith2016-12-141-163/+9
| | | | | | | | | | | copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop. This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here. llvm-svn: 289618
* [clang] Version support for UBSan handlersFilipe Cabecinhas2016-12-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | This adds a way for us to version any UBSan handler by itself. The patch overrides D21289 for a better implementation (we're able to rev up a single handler). After this, then we can land a slight modification of D19667+D19668. We probably don't want to keep all the versions in compiler-rt (maybe we want to deprecate on one release and remove the old handler on the next one?), but with this patch we will loudly fail to compile when mixing incompatible handler calls, instead of silently compiling and then providing bad error messages. Reviewers: kcc, samsonov, rsmith, vsk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21695 llvm-svn: 289444
* PR30937: don't devirtualize if we find that the callee is a pure virtualRichard Smith2016-11-111-23/+20
| | | | | | | | function. In that case, there is no requirement that the callee is actually defined, and the code may in fact be valid and have defined behavior if the virtual call is unreachable. llvm-svn: 286534
* Improve obvious-most-derived-type devirtualization:Richard Smith2016-11-031-37/+15
| | | | | | | | | | | | | | * if the base is produced by a series of derived-to-base conversions, check the expression inside them when looking for an expression with a known dynamic type * step past MaterializeTemporaryExprs when checking for a known dynamic type * when checking for a known dynamic type, treat all class prvalues as having a known dynamic type after skipping all relevant rvalue subobject adjustments * treat callees formed by pointer-to-member access for a non-reference member type like callees formed by member access. llvm-svn: 285954
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-6/+8
| | | | | | | | | | | abstract information about the callee. NFC. The goal here is to make it easier to recognize indirect calls and trigger additional logic in certain cases. That logic will come in a later patch; in the meantime, I felt that this was a significant improvement to the code. llvm-svn: 285258
* [CodeGen] Devirtualize calls to methods marked final in a derived classVedant Kumar2016-10-201-7/+15
| | | | | | | | | | If we see a virtual method call to Base::foo() but can infer that the object is an instance of Derived, and that 'foo' is marked 'final' in Derived, we can devirtualize the call to Derived::foo(). Differential Revision: https://reviews.llvm.org/D25813 llvm-svn: 284766
* When copying an array into a lambda, destroy temporaries fromJohn McCall2016-07-201-0/+35
| | | | | | | | | the copy-constructor immediately and enter a partial array cleanup for previously-copied elements. Fixes PR28595. llvm-svn: 276180
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-46/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* CodeGen: Start emitting checked loads when both trapping CFI and ↵Peter Collingbourne2016-06-251-0/+36
| | | | | | | | -fwhole-program-vtables are enabled. Differential Revision: http://reviews.llvm.org/D21122 llvm-svn: 273757
* CodeGen: Update Clang to use the new type metadata.Peter Collingbourne2016-06-241-20/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D21054 llvm-svn: 273730
* Use more ArrayRefsDavid Majnemer2016-06-241-2/+2
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273647
* Implementation of VlA of GNU C++ extension, by Vladimir Yakovlev.Alexey Bataev2016-04-291-1/+1
| | | | | | | This enables GNU C++ extension "Variable length array" by default. Differential Revision: http://reviews.llvm.org/D18823 llvm-svn: 268018
* Re-apply r267784, r267824 and r267830.Peter Collingbourne2016-04-281-2/+7
| | | | | | I have updated the compiler-rt tests. llvm-svn: 267903
* Revert r267784, r267824 and r267830.Benjamin Kramer2016-04-281-7/+2
| | | | | | | | | | It makes compiler-rt tests fail if the gold plugin is enabled. Revert "Rework interface for bitset-using features to use a notion of LTO visibility." Revert "Driver: only produce CFI -fvisibility= error when compiling." Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi." llvm-svn: 267871
* Rework interface for bitset-using features to use a notion of LTO visibility.Peter Collingbourne2016-04-271-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Bitsets, and the compiler features they rely on (vtable opt, CFI), only have visibility within the LTO'd part of the linkage unit. Therefore, only enable these features for classes with hidden LTO visibility. This notion is based on object file visibility or (on Windows) dllimport/dllexport attributes. We provide the [[clang::lto_visibility_public]] attribute to override the compiler's LTO visibility inference in cases where the class is defined in the non-LTO'd part of the linkage unit, or where the ABI supports calling classes derived from abstract base classes with hidden visibility in other linkage units (e.g. COM on Windows). If the cross-DSO CFI mode is enabled, bitset checks are emitted even for classes with public LTO visibility, as that mode uses a separate mechanism to cause bitsets to be exported. This mechanism replaces the whole-program-vtables blacklist, so remove the -fwhole-program-vtables-blacklist flag. Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the support for the special attr:uuid blacklist entry is removed. Differential Revision: http://reviews.llvm.org/D18635 llvm-svn: 267784
* [modules] Remove CXX_CTOR_INITIALIZERS_OFFSETS table. Instead of storing an IDRichard Smith2016-04-131-1/+1
| | | | | | | | of a table entry in the corresponding decl, store an offset from the current record to the relevant CXX_CTOR_INITIALIZERS record. This results in fewer indirections and a minor .pcm file size reduction. llvm-svn: 266254
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+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
OpenPOWER on IntegriCloud