summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Remove set but unused variable in BitcodeReader.cpp. NFC.Hans Wennborg2017-04-281-4/+0
| | | | llvm-svn: 301713
* 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
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* 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
* 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
* [ThinLTO] Fix lazy-loading of MDString instruction attachmentsMehdi Amini2017-01-201-1/+1
| | | | | | | | | 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
* ThinLTO: add early "dead-stripping" on the IndexTeresa Johnson2017-01-051-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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-051-8/+4
| | | | | | | | | | | | | | | | | | | 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
* Clear the PendingTypeTests vector after moving from it.Peter Collingbourne2016-12-221-0/+2
| | | | | | | This is to put the vector into a well defined state. Apparently the state of a vector after being moved from is valid but unspecified. Found with clang-tidy. llvm-svn: 290298
* IR: Function summary representation for type tests.Peter Collingbourne2016-12-211-2/+12
| | | | | | | | | | | Each function summary has an attached list of type identifier GUIDs. The idea is that during the regular LTO phase we would match these GUIDs to type identifiers defined by the regular LTO module and store the resolutions in a top-level "type identifier summary" (which will be implemented separately). Differential Revision: https://reviews.llvm.org/D27967 llvm-svn: 290280
* IR: Eliminate non-determinism in the module summary analysis.Peter Collingbourne2016-12-201-71/+58
| | | | | | | | | Also make the summary ref and call graph vectors immutable. This means a smaller API surface and fewer places to audit for non-determinism. Differential Revision: https://reviews.llvm.org/D27875 llvm-svn: 290200
* [ThinLTO] Import composite types as declarationsTeresa Johnson2016-12-161-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When reading the metadata bitcode, create a type declaration when possible for composite types when we are importing. Doing this in the bitcode reader saves memory. Also it works naturally in the case when the type ODR map contains a definition for the same composite type because it was used in the importing module (buildODRType will automatically use the existing definition and not create a type declaration). For Chromium built with -g2, this reduces the aggregate size of the generated native object files by 66% (from 31G to 10G). It reduced the time through the ThinLTO link and backend phases by about 20% on my machine. Reviewers: mehdi_amini, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27775 llvm-svn: 289993
* Strip invalid TBAA when reading bitcodeMehdi Amini2016-12-161-0/+24
| | | | | | | | This ensures backward compatibility on bitcode loading. Differential Revision: https://reviews.llvm.org/D27839 llvm-svn: 289977
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-6/+6
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* Refactor BitcodeReader: move Metadata and ValueId handling in their own ↵Mehdi Amini2016-12-121-1395/+22
| | | | | | | | | | | | | | | | | | class/file Summary: I'm planning on changing the way we load metadata to enable laziness. I'm getting lost in this gigantic files, and gigantic class that is the bitcode reader. This is a first toward splitting it in a few coarse components that are more easily understandable. Reviewers: pcc, tejohnson Subscribers: mgorny, llvm-commits, dexonsmith Differential Revision: https://reviews.llvm.org/D27646 llvm-svn: 289461
* Remove IsMetadataMaterialized from BitcodeReader (NFC)Mehdi Amini2016-12-121-5/+1
| | | | | | | | | | | | Summary: It does not seem useful. Reviewers: pcc, dexonsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27668 llvm-svn: 289457
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683
* Bitcode: The index used by ModuleSummaryIndexBitcodeReader is now required, ↵Peter Collingbourne2016-12-011-23/+23
| | | | | | so make it a reference. NFCI. llvm-svn: 288318
* Bitcode: Introduce BitcodeModule::{has,get}Summary().Peter Collingbourne2016-12-011-97/+82
| | | | | | | | These are equivalent to hasGlobalValueSummary() and getModuleSummaryIndex(). Differential Revision: https://reviews.llvm.org/D27242 llvm-svn: 288317
* Bitcode: Change expected layout of module blocks.Peter Collingbourne2016-11-291-10/+35
| | | | | | | | | | | | | | | | | We now expect each module's identification block to appear immediately before the module block. Any module block that appears without an identification block immediately before it is interpreted as if it does not have a module block. Also change the interpretation of VST and function offsets in bitcode. The offset is always taken as relative to the start of the identification (or module if not present) block, minus one word. This corresponds to the historical interpretation of offsets, i.e. relative to the start of the file. These changes allow for bitcode modules to be concatenated by copying bytes. Differential Revision: https://reviews.llvm.org/D27184 llvm-svn: 288098
* Bitcode: Introduce initial multi-module reader API.Peter Collingbourne2016-11-161-49/+99
| | | | | | | | Implement getLazyBitcodeModule() and parseBitcodeFile() in terms of it. Differential Revision: https://reviews.llvm.org/D26719 llvm-svn: 287156
* [ThinLTO] Make inline assembly handling more efficient in summaryTeresa Johnson2016-11-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The change in r285513 to prevent exporting of locals used in inline asm added all locals in the llvm.used set to the reference set of functions containing inline asm. Since these locals were marked NoRename, this automatically prevented importing of the function. Unfortunately, this caused an explosion in the summary reference lists in some cases. In my particular example, it happened for a large protocol buffer generated C++ file, where many of the generated functions contained an inline asm call. It was exacerbated when doing a ThinLTO PGO instrumentation build, where the PGO instrumentation included thousands of private __profd_* values that were added to llvm.used. We really only need to include a single llvm.used local (NoRename) value in the reference list of a function containing inline asm to block it being imported. However, it seems cleaner to add a flag to the summary that explicitly describes this situation, which is what this patch does. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26402 llvm-svn: 286840
* Bitcode: Change module reader functions to return an llvm::Expected.Peter Collingbourne2016-11-131-9/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D26562 llvm-svn: 286752
* Bitcode: More precise casting. NFCI.Peter Collingbourne2016-11-131-3/+3
| | | | llvm-svn: 286750
* Bitcode: Change getModuleSummaryIndex() to return an llvm::Expected.Peter Collingbourne2016-11-111-22/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D26539 llvm-svn: 286624
* Bitcode: Clean up error handling for certain bitcode query functions.Peter Collingbourne2016-11-111-313/+254
| | | | | | | | | | | | | The functions getBitcodeTargetTriple(), isBitcodeContainingObjCCategory(), getBitcodeProducerString() and hasGlobalValueSummary() now return errors via their return value rather than via the diagnostic handler. To make this work, re-implement these functions using non-member functions so that they can be used without the LLVMContext required by BitcodeReader. Differential Revision: https://reviews.llvm.org/D26532 llvm-svn: 286623
* Bitcode: Prepare to move bitcode readers to free functions.Peter Collingbourne2016-11-111-104/+102
| | | | | | | Make initStream() a free function, and change BitcodeReaderBase ctor to take a BitstreamCursor. llvm-svn: 286622
* Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson2016-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Split ReaderWriter.h which contains the APIs into both the BitReader and BitWriter libraries into BitcodeReader.h and BitcodeWriter.h. This is to address Chandler's concern about sharing the same API header between multiple libraries (BitReader and BitWriter). That concern is why we create a single bitcode library in our downstream build of clang, which led to r286297 being reverted as it added a dependency that created a cycle only when there is a single bitcode library (not two as in upstream). Reviewers: mehdi_amini Subscribers: dlj, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D26502 llvm-svn: 286566
OpenPOWER on IntegriCloud