summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-184-8/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* Bitcode: Add missing build dep to fix shlib build.Peter Collingbourne2017-04-171-1/+1
| | | | llvm-svn: 300478
* Bitcode: Add a string table to the bitcode format.Peter Collingbourne2017-04-172-289/+436
| | | | | | | | | | | | | | | | | | | | | | | Add a top-level STRTAB block containing a string table blob, and start storing strings for module codes FUNCTION, GLOBALVAR, ALIAS, IFUNC and COMDAT in the string table. This change allows us to share names between globals and comdats as well as between modules, and improves the efficiency of loading bitcode files by no longer using a bit encoding for symbol names. Once we start writing the irsymtab to the bitcode file we will also be able to share strings between it and the module. On my machine, link time for Chromium for Linux with ThinLTO decreases by about 7% for no-op incremental builds or about 1% for full builds. Total bitcode file size decreases by about 3%. As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-April/111732.html Differential Revision: https://reviews.llvm.org/D31838 llvm-svn: 300464
* Bitcode: Move version and global value module code parsers to separate ↵Peter Collingbourne2017-04-121-240/+276
| | | | | | | | | | functions. NFCI. This will make it easier to teach this code about the string table. Differential Revision: https://reviews.llvm.org/D31828 llvm-svn: 300099
* [IR] Redesign the case iterator in SwitchInst to actually be an iteratorChandler Carruth2017-04-121-1/+1
| | | | | | | | | | | | | | | | and to expose a handle to represent the actual case rather than having the iterator return a reference to itself. All of this allows the iterator to be used with common STL facilities, standard algorithms, etc. Doing this exposed some missing facilities in the iterator facade that I've fixed and required some work to the actual iterator to fully support the necessary API. Differential Revision: https://reviews.llvm.org/D31548 llvm-svn: 300032
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* Bitcode: Merge the code for parsing global value module codes in the summary ↵Peter Collingbourne2017-04-101-26/+6
| | | | | | | | | | | bitcode reader. NFCI. This code will need to be taught to handle string tables and it's better if there is only one copy of it. Differential Revision: https://reviews.llvm.org/D31829 llvm-svn: 299886
* Bitcode: Do not create FNENTRYs for aliases of functions.Peter Collingbourne2017-04-062-18/+5
| | | | | | | | There doesn't seem to be any point in doing this. Differential Revision: https://reviews.llvm.org/D31691 llvm-svn: 299694
* Bitcode: Remove an unused declaration. NFC.Peter Collingbourne2017-04-051-1/+0
| | | | llvm-svn: 299598
* Bitcode: Remove reader support for MODULE_CODE_PURGEVALS.Peter Collingbourne2017-04-031-7/+0
| | | | | | | | | | Support for writing this module code was removed in r73220, which was well before the LLVM 3.0 release, so we do not need to be able to understand it for backwards compatibility. Differential Revision: https://reviews.llvm.org/D31563 llvm-svn: 299370
* Spelling mistakes in comments. NFCI.Simon Pilgrim2017-03-301-1/+1
| | | | | | Based on corrections mentioned in patch for clang for PR27635 llvm-svn: 299072
* [IR] Add AllowContract to FastMathFlagsAdam Nemet2017-03-282-0/+4
| | | | | | | | | | | | -ffp-contract=fast does not currently work with LTO because it's passed as a TargetOption to the backend rather than in the IR. This adds it to FastMathFlags. This is toward fixing PR25721 Differential Revision: https://reviews.llvm.org/D31164 llvm-svn: 298939
* [ThinLTO] Add support for emitting minimized bitcode for thin linkTeresa Johnson2017-03-231-20/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
* Rename AttributeSet to AttributeListReid Kleckner2017-03-214-32/+30
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* SamplePGO ThinLTO ICP fix for local functions.Dehao Chen2017-03-142-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In SamplePGO, if the profile is collected from non-LTO binary, and used to drive ThinLTO, the indirect call promotion may fail because ThinLTO adjusts local function names to avoid conflicts. There are two places of where the mismatch can happen: 1. thin-link prepends SourceFileName to front of FuncName to build the GUID (GlobalValue::getGlobalIdentifier). Unlike instrumentation FDO, SamplePGO does not use the PGOFuncName scheme and therefore the indirect call target profile data contains a hash of the OriginalName. 2. backend compiler promotes some local functions to global and appends .llvm.{$ModuleHash} to the end of the FuncName to derive PromotedFunctionName This patch tries at the best effort to find the GUID from the original local function name (in profile), and use that in ICP promotion, and in SamplePGO matching that happens in the backend after importing/inlining: 1. in thin-link, it builds the map from OriginalName to GUID so that when thin-link reads in indirect call target profile (represented by OriginalName), it knows which GUID to import. 2. in backend compiler, if sample profile reader cannot find a profile match for PromotedFunctionName, it will try to find if there is a match for OriginalFunctionName. 3. in backend compiler, we build symbol table entry for OriginalFunctionName and pointer to the same symbol of PromotedFunctionName, so that ICP can find the correct target to promote. Reviewers: mehdi_amini, tejohnson Reviewed By: tejohnson Subscribers: llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D30754 llvm-svn: 297757
* [DebugInfo] Emit address space with DW_AT_address_class attribute for ↵Konstantin Zhuravlyov2017-03-082-2/+16
| | | | | | | | pointer and reference types Differential Revision: https://reviews.llvm.org/D29670 llvm-svn: 297320
* Move symbols from the global namespace into (anonymous) namespaces. NFC.Benjamin Kramer2017-02-112-2/+2
| | | | llvm-svn: 294837
* Address Mehdi's post-commit review comments on r294795.Peter Collingbourne2017-02-111-0/+4
| | | | llvm-svn: 294822
* IR: Function summary extensions for whole-program devirtualization pass.Peter Collingbourne2017-02-102-6/+87
| | | | | | | | | | The summary information includes all uses of llvm.type.test and llvm.type.checked.load intrinsics that can be used to devirtualize calls, including any constant arguments for virtual constant propagation. Differential Revision: https://reviews.llvm.org/D29734 llvm-svn: 294795
* Fix bitcode upgrade for DIGlobalVariables with a var: field.Adrian Prantl2017-02-081-2/+1
| | | | | | | | | | | | | | | This is a follow-up to https://reviews.llvm.org/D29349. It turns out that NeedUpgradeToDIGlobalVariableExpression is always necessary when we encountered a version==0 record because it may always be referenced via a list of globals in a DICompileUnit. My tests weren't good enough to catch this though. To trigger this case, we need much older bitcode produced by LLVM around version 3.7. <rdar://problem/30404262> Differential Revision: https://reviews.llvm.org/D29693 llvm-svn: 294488
* Fix the bitcode upgrade for DIGlobalVariable in a DIImportedEntity context.Adrian Prantl2017-02-071-5/+51
| | | | | | | | | | | | | | | The bitcode upgrade for DIGlobalVariable unconditionally wrapped DIGlobalVariables in a DIGlobalVariableExpression. When a DIGlobalVariable is referenced by a DIImportedEntity, however, this is wrong. This patch fixes the bitcode upgrade by deferring the creation of DIGlobalVariableExpressions until we know the context of the DIGlobalVariable. <rdar://problem/30134279> Differential Revision: https://reviews.llvm.org/D29349 llvm-svn: 294318
* Revert "[ThinLTO] Add an auto-hide feature"Mehdi Amini2017-02-032-9/+8
| | | | | | | | | This reverts commit r293970. After more discussion, this belongs to the linker side and there is no added value to do it at this level. llvm-svn: 293993
* [ThinLTO] Add an auto-hide featureMehdi Amini2017-02-032-8/+9
| | | | | | | | | | | | | | | When a symbol is not exported outside of the DSO, it is can be hidden. Usually we try to internalize as much as possible, but it is not always possible, for instance a symbol can be referenced outside of the LTO unit, or there can be cross-module reference in ThinLTO. This is a recommit of r293912 after fixing build failures, and a recommit of r293918 after fixing LLD tests. Differential Revision: https://reviews.llvm.org/D28978 llvm-svn: 293970
* Revert "[ThinLTO] Add an auto-hide feature"Mehdi Amini2017-02-022-9/+8
| | | | | | This reverts commit r293918, one lld test does not pass. llvm-svn: 293961
* [ThinLTO] Add an auto-hide featureMehdi Amini2017-02-022-8/+9
| | | | | | | | | | | | | | When a symbol is not exported outside of the DSO, it is can be hidden. Usually we try to internalize as much as possible, but it is not always possible, for instance a symbol can be referenced outside of the LTO unit, or there can be cross-module reference in ThinLTO. This is a recommit of r293912 after fixing build failures. Differential Revision: https://reviews.llvm.org/D28978 llvm-svn: 293918
* Revert "[ThinLTO] Add an auto-hide feature"Mehdi Amini2017-02-022-9/+8
| | | | | | This reverts r293912, bots are broken. llvm-svn: 293914
* [ThinLTO] Add an auto-hide featureMehdi Amini2017-02-022-8/+9
| | | | | | | | | | | | When a symbol is not exported outside of the DSO, it is can be hidden. Usually we try to internalize as much as possible, but it is not always possible, for instance a symbol can be referenced outside of the LTO unit, or there can be cross-module reference in ThinLTO. Differential Revision: https://reviews.llvm.org/D28978 llvm-svn: 293912
* Change debug-info-for-profiling from a TargetOption to a function attribute.Dehao Chen2017-02-012-2/+4
| | | | | | | | | | | | | | Summary: LTO requires the debug-info-for-profiling to be a function attribute. Reviewers: echristo, mehdi_amini, dblaikie, probinson, aprantl Reviewed By: mehdi_amini, dblaikie, aprantl Subscribers: aprantl, probinson, ahatanak, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D29203 llvm-svn: 293833
* Cleanup dump() functions.Matthias Braun2017-01-281-1/+4
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* Avoid using unspecified ordering in ↵Ivan Krasin2017-01-271-33/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MetadataLoader::MetadataLoaderImpl::parseOneMetadata. Summary: MetadataLoader::MetadataLoaderImpl::parseOneMetadata uses the following construct in a number of places: ``` MetadataList.assignValue(<...>, NextMetadataNo++); ``` There, NextMetadataNo gets incremented, and since the order of arguments evaluation is not specified, that can happen before or after other arguments are evaluated. In a few cases the other arguments indirectly use NextMetadataNo. For instance, it's ``` MetadataList.assignValue( GET_OR_DISTINCT(DIModule, (Context, getMDOrNull(Record[1]), getMDString(Record[2]), getMDString(Record[3]), getMDString(Record[4]), getMDString(Record[5]))), NextMetadataNo++); ``` getMDOrNull calls getMD that uses NextMetadataNo: ``` MetadataList.getMetadataFwdRef(NextMetadataNo); ``` Therefore, the order of evaluation becomes important. That caused a very subtle LLD crash that only happens if compiled with GCC or if LLD is built with LTO. In the case if LLD is compiled with Clang and regular linking mode, everything worked as intended. This change extracts incrementing of NextMetadataNo outside of the arguments list to guarantee the correct order of evaluation. For the record, this has taken 3 days to track to the origin. It all started with a ThinLTO bot in Chrome not being able to link a target if debug info is enabled. Reviewers: pcc, mehdi_amini Reviewed By: mehdi_amini Subscribers: aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D29204 llvm-svn: 293291
* [ThinLTO] Fix lazy-loading of MDString instruction attachmentsMehdi Amini2017-01-203-6/+19
| | | | | | | | | CFI is using intrinsics that takes MDString as arguments, and this was broken during lazy-loading of metadata. Differential Revision: https://reviews.llvm.org/D28916 llvm-svn: 292641
* Add an assertion to PlaceholderQueue destructor, ensuring it has been flushedMehdi Amini2017-01-201-0/+3
| | | | llvm-svn: 292597
* [ThinLTO] Add a recursive step in Metadata lazy-loadingMehdi Amini2017-01-181-4/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: Without this, we're stressing the RAUW of unique nodes, which is a costly operation. This is intended to limit the number of RAUW, and is very effective on the total link-time of opt with ThinLTO, before: real 4m4.587s user 15m3.401s sys 0m23.616s after: real 3m25.261s user 12m22.132s sys 0m24.152s Reviewers: tejohnson, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28751 llvm-svn: 292420
* Remove unused lambda captures. NFCMalcolm Parsons2017-01-131-1/+1
| | | | llvm-svn: 291916
* Apply clang-tidy's performance-unnecessary-value-param to LLVM.Benjamin Kramer2017-01-131-5/+5
| | | | | | | With some minor manual fixes for using function_ref instead of std::function. No functional change intended. llvm-svn: 291904
* [ThinLTO] Fix lazy-loading of Metadata attachment, which left some Fwd ref ↵Mehdi Amini2017-01-081-1/+2
| | | | | | | | | | | behind The change in r291362 was too agressive. We still need to flush at the end of the block because function local metadata can introduce fwd ref as well. (Bootstrap with ThinLTO was broken) llvm-svn: 291379
* [ThinLTO] Fix assertions on lazy-loading of Metadata TBAA attachmentsMehdi Amini2017-01-071-4/+4
| | | | | | | | | | | | | | | | | | | | | Summary: The issue happens with: %0 = ....., !tbaa !0 %1 = ....., !tbaa !1 With !0 that references !1. In this case when loading !0 we generates a temporary for the operand !1. We now flush it immediately and trigger the load of !1 before moving on. If we don't we get the temporary when attaching to %1. This is usually not an issue except that we eagerly try to update TBAA MDNodes, which is obviously not possible if we only have a temporary. Differential Revision: https://reviews.llvm.org/D28423 llvm-svn: 291362
* [Bitcode] Remove unused PlaceHolder parameter to lazyLoadModuleMetadataBlock()Mehdi Amini2017-01-071-4/+4
| | | | llvm-svn: 291356
* ThinLTO: add early "dead-stripping" on the IndexTeresa Johnson2017-01-052-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Using the linker-supplied list of "preserved" symbols, we can compute the list of "dead" symbols, i.e. the one that are not reachable from a "preserved" symbol transitively on the reference graph. Right now we are using this information to mark these functions as non-eligible for import. The impact is two folds: - Reduction of compile time: we don't import these functions anywhere or import the function these symbols are calling. - The limited number of import/export leads to better internalization. Patch originally by Mehdi Amini. Reviewers: mehdi_amini, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23488 llvm-svn: 291177
* [ThinLTO] Subsume all importing checks into a single flagTeresa Johnson2017-01-052-12/+6
| | | | | | | | | | | | | | | | | | | Summary: This adds a new summary flag NotEligibleToImport that subsumes several existing flags (NoRename, HasInlineAsmMaybeReferencingInternal and IsNotViableToInline). It also subsumes the checking of references on the summary that was being done during the thin link by eligibleForImport() for each candidate. It is much more efficient to do that checking once during the per-module summary build and record it in the summary. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28169 llvm-svn: 291108
* Use lazy-loading of Metadata in MetadataLoader when importing is enabled (NFC)Mehdi Amini2017-01-041-27/+373
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a relatively simple scheme: we use the index emitted in the bitcode to avoid loading all the global metadata. Instead we load the index with their position in the bitcode so that we can load each of them individually. Materializing the global metadata block in this condition only triggers loading the named metadata, and the ones referenced from there (transitively). When materializing a function, metadata from the global block are loaded lazily as they are referenced. Two main current limitations are: 1) Global values other than functions are not materialized on demand, so we need to eagerly load METADATA_GLOBAL_DECL_ATTACHMENT records (and their transitive dependencies). 2) When we load a single metadata, we don't recurse on the operands, instead we use a placeholder or a temporary metadata. Unfortunately tepmorary nodes are very expensive. This is why we don't have it always enabled and only for importing. These two limitations can be lifted in a subsequent improvement if needed. With this change, the total link time of opt with ThinLTO and Debug Info enabled is going down from 282s to 224s (~20%). Reviewers: pcc, tejohnson, dexonsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28113 llvm-svn: 291027
* Change BitstreamCursor::skipRecord to return the record code (NFC)Mehdi Amini2017-01-041-4/+14
| | | | llvm-svn: 291026
* Reapply "Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie2017-01-042-94/+94
| | | | | | | | | | | | | | | | | IntrusiveRefCntPtr"" If this is a problem for anyone (shared_ptr is two pointers in size, whereas IntrusiveRefCntPtr is 1 - and the ref count control block that make_shared adds is probably larger than the one int in RefCountedBase) I'd prefer to address this by adding a lower-overhead version of shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing) to avoid the intrusiveness - this allows memory ownership to remain orthogonal to types and at least to me, seems to make code easier to understand (since no implicit ownership acquisition can happen). This recommits 291006, reverted in r291007. llvm-svn: 291016
* Revert "Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie2017-01-042-94/+94
| | | | | | | | | | | IntrusiveRefCntPtr" Breaks Clang's use of bitcode. Reverting until I have a fix to go with it there. This reverts commit r291006. llvm-svn: 291007
* Make BitCodeAbbrev ownership explicit using shared_ptr rather than ↵David Blaikie2017-01-042-94/+94
| | | | | | | | | | | | | | | IntrusiveRefCntPtr If this is a problem for anyone (shared_ptr is two pointers in size, whereas IntrusiveRefCntPtr is 1 - and the ref count control block that make_shared adds is probably larger than the one int in RefCountedBase) I'd prefer to address this by adding a lower-overhead version of shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing) to avoid the intrusiveness - this allows memory ownership to remain orthogonal to types and at least to me, seems to make code easier to understand (since no implicit ownership acquisition can happen). llvm-svn: 291006
* [ThinLTO] Import type as decl only when non-null IdentifierTeresa Johnson2017-01-031-1/+1
| | | | | | | | As per post-commit review for r289993 (D27775), we can only safely import a type as a decl if it has an Identifier, as the Name alone is not enough to be unique across modules. llvm-svn: 290915
* Change Metadata Index emission in the bitcode to use 2x32 bits for the ↵Mehdi Amini2016-12-281-2/+3
| | | | | | | | | | placeholder The Bitstream reader and writer are limited to handle a "size_t" at most, which means that we can't backpatch and read back a 64bits value on 32 bits platform. llvm-svn: 290693
* Add an index for Module Metadata record in the bitcodeMehdi Amini2016-12-281-5/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | This index record the position for each metadata record in the bitcode, so that the reader will be able to lazy-load on demand each individual record. We also make sure that every abbrev is emitted upfront so that the block can be skipped while reading. I don't plan to commit this before having the reader counterpart, but I figured this can be reviewed mostly independently. Recommit r290684 (was reverted in r290686 because a test was broken) after adding a threshold to avoid emitting the index when unnecessary (little amount of metadata). This optimization "hides" a limitation of the ability to backpatch in the bitstream: we can only backpatch safely when the position has been flushed. So if we emit an index for one metadata, it is possible that (part of) the offset placeholder hasn't been flushed and the backpatch will fail. Differential Revision: https://reviews.llvm.org/D28083 llvm-svn: 290690
* Revert "Add an index for Module Metadata record in the bitcode"Saleem Abdulrasool2016-12-281-80/+5
| | | | | | | This reverts commit a0ca6ae2d38339e4ede0dfa588086fc23d87e836. Revert at Mehdi's request as it is breaking bots. llvm-svn: 290686
* Add an index for Module Metadata record in the bitcodeMehdi Amini2016-12-281-5/+80
| | | | | | | | | | | | | | | | | | | | | | Summary: This index record the position for each metadata record in the bitcode, so that the reader will be able to lazy-load on demand each individual record. We also make sure that every abbrev is emitted upfront so that the block can be skipped while reading. I don't plan to commit this before having the reader counterpart, but I figured this can be reviewed mostly independently. Reviewers: pcc, tejohnson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28083 llvm-svn: 290684
OpenPOWER on IntegriCloud