summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
AgeCommit message (Collapse)Author
2016-12-16Strip invalid TBAA when reading bitcodeMehdi Amini
This ensures backward compatibility on bitcode loading. Differential Revision: https://reviews.llvm.org/D27839 llvm-svn: 289977
2016-12-14Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann
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
2016-12-12Refactor BitcodeReader: move Metadata and ValueId handling in their own ↵Mehdi Amini
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
2016-12-12Remove IsMetadataMaterialized from BitcodeReader (NFC)Mehdi Amini
Summary: It does not seem useful. Reviewers: pcc, dexonsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27668 llvm-svn: 289457
2016-12-05[DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl
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
2016-12-01Bitcode: The index used by ModuleSummaryIndexBitcodeReader is now required, ↵Peter Collingbourne
so make it a reference. NFCI. llvm-svn: 288318
2016-12-01Bitcode: Introduce BitcodeModule::{has,get}Summary().Peter Collingbourne
These are equivalent to hasGlobalValueSummary() and getModuleSummaryIndex(). Differential Revision: https://reviews.llvm.org/D27242 llvm-svn: 288317
2016-11-29Bitcode: Change expected layout of module blocks.Peter Collingbourne
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
2016-11-16Bitcode: Introduce initial multi-module reader API.Peter Collingbourne
Implement getLazyBitcodeModule() and parseBitcodeFile() in terms of it. Differential Revision: https://reviews.llvm.org/D26719 llvm-svn: 287156
2016-11-14[ThinLTO] Make inline assembly handling more efficient in summaryTeresa Johnson
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
2016-11-13Bitcode: Change module reader functions to return an llvm::Expected.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26562 llvm-svn: 286752
2016-11-13Bitcode: More precise casting. NFCI.Peter Collingbourne
llvm-svn: 286750
2016-11-11Bitcode: Change getModuleSummaryIndex() to return an llvm::Expected.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26539 llvm-svn: 286624
2016-11-11Bitcode: Clean up error handling for certain bitcode query functions.Peter Collingbourne
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
2016-11-11Bitcode: Prepare to move bitcode readers to free functions.Peter Collingbourne
Make initStream() a free function, and change BitcodeReaderBase ctor to take a BitstreamCursor. llvm-svn: 286622
2016-11-11Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson
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
2016-11-11Prevent at compile time converting from Error::success() to Expected<T>Mehdi Amini
This would trigger an assertion at runtime otherwise. Differential Revision: https://reviews.llvm.org/D26482 llvm-svn: 286562
2016-11-10IR: Introduce inrange attribute on getelementptr indices.Peter Collingbourne
If the inrange keyword is present before any index, loading from or storing to any pointer derived from the getelementptr has undefined behavior if the load or store would access memory outside of the bounds of the element selected by the index marked as inrange. This can be used, e.g. for alias analysis or to split globals at element boundaries where beneficial. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html Differential Revision: https://reviews.llvm.org/D22793 llvm-svn: 286514
2016-11-09Make BitcodeReader::parseIdentificationBlock() robust to EOFMehdi Amini
This method is particular: it iterates at the top-level and does not have an enclosing block. llvm-svn: 286394
2016-11-09Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
2016-11-09Bitcode: Remove the remnants of the BitcodeDiagnosticInfo class.Peter Collingbourne
The BitcodeReader no longer produces BitcodeDiagnosticInfo diagnostics. The only remaining reference was in the gold plugin; the code there has been dead since we stopped producing InvalidBitcodeSignature error codes in r225562. While at it remove the InvalidBitcodeSignature error code. llvm-svn: 286326
2016-11-09Bitcode: Change the BitcodeReader to use llvm::Error internally.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26430 llvm-svn: 286323
2016-11-08IR, Bitcode: Change bitcode reader to no longer own its memory buffer.Peter Collingbourne
Unique ownership is just one possible ownership pattern for the memory buffer underlying the bitcode reader. In practice, as this patch shows, ownership can often reside at a higher level. With the upcoming change to allow multiple modules in a single bitcode file, it will no longer be appropriate for modules to generally have unique ownership of their memory buffer. The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for the module to own the memory buffer. This patch does so by adding an owned memory buffer field to Module, and using it in a few other places where it is convenient. Differential Revision: https://reviews.llvm.org/D26384 llvm-svn: 286214
2016-11-08Bitcode: Decouple block info block state from reader.Peter Collingbourne
As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html Move block info block state to a new class, BitstreamBlockInfo. Clients may set the block info for a particular cursor with the BitstreamCursor::setBlockInfo() method. At this point BitstreamReader is not much more than a container for an ArrayRef<uint8_t>, so remove it and replace all uses with direct uses of memory buffers. Differential Revision: https://reviews.llvm.org/D26259 llvm-svn: 286207
2016-11-08Bitcode: Split out block info reading into a separate function.Peter Collingbourne
We're about to make this more complicated. llvm-svn: 286206
2016-11-06Kill deprecated attribute APIAmaury Sechet
Summary: This kill various depreacated API related to attribute : - The deprecated C API attribute based on LLVMAttribute enum. - The Raw attribute set format (planned to be removed in 4.0). Reviewers: bkramer, echristo, mehdi_amini, void Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23039 llvm-svn: 286062
2016-11-03Add DWARF debug info support for C++11 inline namespaces.Adrian Prantl
This implements the DWARF 5 DW_AT_export_symbols feature: http://dwarfstd.org/ShowIssue.php?issue=141212.1 <rdar://problem/18616046> llvm-svn: 285959
2016-11-02Bitcode: Check file size before reading bitcode header.Peter Collingbourne
Should unbreak ocaml binding tests. Also added an llvm-dis test that checks for the same thing. llvm-svn: 285777
2016-11-02Bitcode: Change reader interface to take memory buffers.Peter Collingbourne
As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html This change also fixes an API oddity where BitstreamCursor::Read() would return zero for the first read past the end of the bitstream, but would report_fatal_error for subsequent reads. Now we always report_fatal_error for all reads past the end. Updated clients to check for the end of the bitstream before reading from it. I also needed to add padding to the invalid bitcode tests in test/Bitcode/. This is because the streaming interface was not checking that the file size is a multiple of 4. Differential Revision: https://reviews.llvm.org/D26219 llvm-svn: 285773
2016-10-28[ThinLTO] Rename HasSection to NoRename (NFC)Teresa Johnson
Summary: This is in preparation for a change to utilize this flag for symbols referenced/defined in either inline or module level assembly. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26048 llvm-svn: 285376
2016-10-26DebugInfo: fix incorrect alignment type (NFC)Victor Leschuk
Change type of some missed DebugInfo-related alignment variables, that are still uint64_t, to uint32_t. Original change introduced in r284482. llvm-svn: 285242
2016-10-20DebugInfo: preparation to implement DW_AT_alignmentVictor Leschuk
- Add alignment attribute to DIVariable family - Modify bitcode format to match new DIVariable representation - Update tests to match these changes (also add bitcode upgrade test) - Expect that frontend passes non-zero align value only when it is not default (was forcibly aligned by alignas()/_Alignas()/__atribute__(aligned()) Differential Revision: https://reviews.llvm.org/D25073 llvm-svn: 284678
2016-10-19Remove LLVM_NOEXCEPT and replace it with noexceptReid Kleckner
Now that we have dropped MSVC 2013, all supported compilers support noexcept and we can drop this portability macro. llvm-svn: 284672
2016-10-18DebugInfo: change alignment type from uint64_t to uint32_t to save space.Victor Leschuk
In futher patches we shall have alignment field added to DIVariable family and switching from uint64_t to uint32_t will save 4 bytes per variable. Differential Revision: https://reviews.llvm.org/D25620 llvm-svn: 284482
2016-10-08ThinLTO: handles modules with empty summariesMehdi Amini
We need to add an entry in the combined-index for modules that have a hash but otherwise empty summary, this is needed so that we can get the hash for the module. Also, if no entry is present in the combined index for a module, we need to skip it when trying to compute a cache entry. Differential Revision: https://reviews.llvm.org/D25300 llvm-svn: 283654
2016-09-26[thinlto] Basic thinlto fdo heuristicPiotr Padlewski
Summary: This patch improves thinlto importer by importing 3x larger functions that are called from hot block. I compared performance with the trunk on spec, and there were about 2% on povray and 3.33% on milc. These results seems to be consistant and match the results Teresa got with her simple heuristic. Some benchmarks got slower but I think they are just noisy (mcf, xalancbmki, omnetpp)- running the benchmarks again with more iterations to confirm. Geomean of all benchmarks including the noisy ones were about +0.02%. I see much better improvement on google branch with Easwaran patch for pgo callsite inlining (the inliner actually inline those big functions) Over all I see +0.5% improvement, and I get +8.65% on povray. So I guess we will see much bigger change when Easwaran patch will land (it depends on new pass manager), but it is still worth putting this to trunk before it. Implementation details changes: - Removed CallsiteCount. - ProfileCount got replaced by Hotness - hot-import-multiplier is set to 3.0 for now, didn't have time to tune it up, but I see that we get most of the interesting functions with 3, so there is no much performance difference with higher, and binary size doesn't grow as much as with 10.0. Reviewers: eraman, mehdi_amini, tejohnson Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D24638 llvm-svn: 282437
2016-09-23BitcodeReader: Deduplicate code. NFC.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D24852 llvm-svn: 282272
2016-09-20[ThinLTO] Always emit a summary when compiling in ThinLTO modeTeresa Johnson
Summary: Emit an empty summary section, instead of no summary section, when there are no global variables in the index. This ensures that LTO will treat these files as ThinLTO inputs, instead of as regular LTO inputs. In addition to not being what the user likely intended when compiling with -flto=thin, the current behavior is problematic for distributed build systems that expect to get ThinLTO index and imports files back for each input compiled with -flto=thin. Combining into a single regular LTO module also reduces the backend parallelism. And in the case where the index was suppressed due to uses in inline assembly, combining into a single LTO module could provoke renaming of duplicates that we were trying to prevent by suppressing the index. This change required a couple of fixes to handle the empty summary section. Reviewers: mehdi_amini Subscribers: mehdi_amini, llvm-commits, pcc Differential Revision: https://reviews.llvm.org/D24779 llvm-svn: 282037
2016-09-14Fix auto-upgrade of TBAA tags in Bitcode ReaderMehdi Amini
If TBAA is on an intrinsic and it gets upgraded, it'll delete the call instruction that we collected in a vector. Even if we were to use WeakVH, it'll drop the TBAA and we'll hit the assert on the upgrade path. r263673 gave a shot to make sure the TBAA upgrade happens before intrinsics upgrade, but failed to account for all cases. Instead of collecting instructions in a vector, this patch makes it just upgrade the TBAA on the fly, because metadata are always already loaded at this point. Differential Revision: https://reviews.llvm.org/D24533 llvm-svn: 281549
2016-09-13DebugInfo: New metadata representation for global variables.Peter Collingbourne
This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
2016-09-06Formatting with clang-format patch r280700Leny Kholodov
llvm-svn: 280716
2016-09-06DebugInfo: use strongly typed enum for debug info flagsLeny Kholodov
Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280700
2016-09-06Revert "DebugInfo: use strongly typed enum for debug info flags"Mehdi Amini
This reverts commit r280686, bots are broken. llvm-svn: 280688
2016-09-06DebugInfo: use strongly typed enum for debug info flagsMehdi Amini
Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: * Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 * Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280686
2016-08-25Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko
other minor fixes. Differential revision: https://reviews.llvm.org/D23861 llvm-svn: 279695
2016-08-24DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie
skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279650
2016-08-17Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner
This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-08-14Fix bitcode auto-upgrade when using bitcode lazy loadingMehdi Amini
The auto-upgrade path could be called before the VST (global names) was fully parsed, and thus intrinsic names were not available and the autoupgrade logic could not operate. Fix link failures with ThinLTO. This is a recommit of r278610 with a different fix. llvm-svn: 278615
2016-08-13Revert "Fix bitcode auto-upgrade when using bitcode lazy loading"Mehdi Amini
This reverts commit r278610. Tests are broken llvm-svn: 278613
2016-08-13Fix bitcode auto-upgrade when using bitcode lazy loadingMehdi Amini
The auto-upgrade path could be called before the VST (global names) was fully parsed, and thus intrinsic names were not available and the autoupgrade logic could not operate. Fix link failures with ThinLTO. llvm-svn: 278610
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-01 11:51:48 +0000