summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader
Commit message (Collapse)AuthorAgeFilesLines
...
* [IR] Allow attributes with global variablesJaved Absar2017-05-111-1/+6
| | | | | | | | | | | | | This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
* Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne2017-05-041-36/+41
| | | | | | | | the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
* Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu2017-05-041-41/+36
| | | | | | | | | | summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. llvm-svn: 302140
* IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne2017-05-041-36/+41
| | | | | | | | | | | | | | | | | | | | NFCI. When profiling a no-op incremental link of Chromium I found that the functions computeImportForFunction and computeDeadSymbols were consuming roughly 10% of the profile. The goal of this change is to improve the performance of those functions by changing the map lookups that they were previously doing into pointer dereferences. This is achieved by changing the ValueInfo data structure to be a pointer to an element of the global value map owned by ModuleSummaryIndex, and changing reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs. This means that a ValueInfo will take a client directly to the summary list for a given GUID. Differential Revision: https://reviews.llvm.org/D32471 llvm-svn: 302108
* Fix a pessimising move warning.Peter Collingbourne2017-05-011-5/+1
| | | | llvm-svn: 301852
* Bitcode: Make the summary reader responsible for merging. NFCI.Peter Collingbourne2017-05-011-23/+62
| | | | | | | | | This is to prepare for an upcoming change which uses pointers instead of GUIDs to represent references. Differential Revision: https://reviews.llvm.org/D32469 llvm-svn: 301843
* Object: Remove ModuleSummaryIndexObjectFile class.Peter Collingbourne2017-05-011-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D32195 llvm-svn: 301832
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-05-012-2/+2
| | | | | | This relands r301424. llvm-svn: 301812
* Remove set but unused variable in BitcodeReader.cpp. NFC.Hans Wennborg2017-04-281-4/+0
| | | | llvm-svn: 301713
* Remove line and file from DINamespace.Adrian Prantl2017-04-281-4/+8
| | | | | | | | | | | | | | Fixes the issue highlighted in http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html. The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can prevent LLVM from uniquing types that are in the same namespace. They also don't carry any meaningful information. rdar://problem/17484998 Differential Revision: https://reviews.llvm.org/D32648 llvm-svn: 301706
* Add speculatable function attributeMatt Arsenault2017-04-281-0/+3
| | | | | | | | This attribute tells the optimizer that the function may be speculated. Patch by Tom Stellard llvm-svn: 301680
* Bitcode: Do not remove empty summary entries when reading a per-module summary.Peter Collingbourne2017-04-281-10/+0
| | | | | | | | This became no longer necessary after D19462 landed, and will be incompatible with an upcoming change to the summary data structures that changes how we represent references. llvm-svn: 301660
* Turn DISubprogram into a variable-length node.Adrian Prantl2017-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | DISubprogram currently has 10 pointer operands, several of which are often nullptr. This patch reduces the amount of memory allocated by DISubprogram by rearranging the operands such that containing type, template params, and thrown types come last, and are only allocated when they are non-null (or followed by non-null operands). This patch also eliminates the entirely unused DisplayName operand. This saves up to 4 pointer operands per DISubprogram. (I tried measuring the effect on peak memory usage on an LTO link of an X86 llc, but the results were very noisy). This reapplies r301498 with an attempted workaround for g++. Differential Revision: https://reviews.llvm.org/D32560 llvm-svn: 301501
* Revert "Turn DISubprogram into a variable-length node."Adrian Prantl2017-04-261-2/+2
| | | | | | This reverts commit r301498 while investigating bot breakage. llvm-svn: 301499
* Turn DISubprogram into a variable-length node.Adrian Prantl2017-04-261-2/+2
| | | | | | | | | | | | | | | | DISubprogram currently has 10 pointer operands, several of which are often nullptr. This patch reduces the amount of memory allocated by DISubprogram by rearranging the operands such that containing type, template params, and thrown types come last, and are only allocated when they are non-null (or followed by non-null operands). This patch also eliminates the entirely unused DisplayName operand. This saves up to 4 pointer operands per DISubprogram. (I tried measuring the effect on peak memory usage on an LTO link of an X86 llc, but the results were very noisy). llvm-svn: 301498
* Add support for DW_TAG_thrown_type.Adrian Prantl2017-04-261-23/+25
| | | | | | | | | | | | | | | | | | | | For Swift we would like to be able to encode the error types that a function may throw, so the debugger can display them alongside the function's return value when finish-ing a function. DWARF defines DW_TAG_thrown_type (intended to be used for C++ throw() declarations) that is a perfect fit for this purpose. This patch wires up support for DW_TAG_thrown_type in LLVM by adding a list of thrown types to DISubprogram. To offset the cost of the extra pointer, there is a follow-up patch that turns DISubprogram into a variable-length node. rdar://problem/29481673 Differential Revision: https://reviews.llvm.org/D32559 llvm-svn: 301489
* Reverts commit r301424, r301425 and r301426Sanjoy Das2017-04-262-2/+2
| | | | | | | | | | | | Commits were: "Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts" "Add a new WeakVH value handle; NFC" "Rename WeakVH to WeakTrackingVH; NFC" The changes assumed pointers are 8 byte aligned on all architectures. llvm-svn: 301429
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-04-262-2/+2
| | | | | | | | | | | | | | | | Summary: I plan to use WeakVH to mean "nulls itself out on deletion, but does not track RAUW" in a subsequent commit. Reviewers: dblaikie, davide Reviewed By: davide Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle Differential Revision: https://reviews.llvm.org/D32266 llvm-svn: 301424
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-183-5/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 a string table to the bitcode format.Peter Collingbourne2017-04-171-78/+237
| | | | | | | | | | | | | | | | | | | | | | | 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
* 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-061-11/+5
| | | | | | | | There doesn't seem to be any point in doing this. Differential Revision: https://reviews.llvm.org/D31691 llvm-svn: 299694
* 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-281-0/+2
| | | | | | | | | | | | -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
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 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-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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-081-2/+9
| | | | | | | | 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-111-1/+1
| | | | 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-101-2/+42
| | | | | | | | | | 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-031-5/+4
| | | | | | | | | 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-031-4/+5
| | | | | | | | | | | | | | | 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-021-5/+4
| | | | | | This reverts commit r293918, one lld test does not pass. llvm-svn: 293961
* [ThinLTO] Add an auto-hide featureMehdi Amini2017-02-021-4/+5
| | | | | | | | | | | | | | 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-021-5/+4
| | | | | | This reverts r293912, bots are broken. llvm-svn: 293914
* [ThinLTO] Add an auto-hide featureMehdi Amini2017-02-021-4/+5
| | | | | | | | | | | | 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-011-2/+3
| | | | | | | | | | | | | | 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
* 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
* 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
OpenPOWER on IntegriCloud