summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* Add testing for mismatched explicit type on a gep operator when loading from ↵David Blaikie2015-03-161-1/+2
| | | | | | bitcode llvm-svn: 232427
* Add testing for mismatched explicit type on a load instruction when loading ↵David Blaikie2015-03-161-3/+3
| | | | | | from bitcode llvm-svn: 232424
* Test bitcode parsing error-handling for incorrect explicit typeDavid Blaikie2015-03-161-2/+8
| | | | | | | | (turns out I had regressed this when sinking handling of this type down into GetElementPtrInst::Create - since that asserted before the error handling was performed) llvm-svn: 232420
* [opaque pointer type] more gep API migrationDavid Blaikie2015-03-141-1/+1
| | | | llvm-svn: 232274
* Be lazy about loading metadata in IRObjectFile.Rafael Espindola2015-03-131-1/+1
| | | | | | | This speeds up llvm-ar building lib64/libclangSema.a with debug IR files from 8.658015807 seconds to just 0.351036519 seconds :-) llvm-svn: 232221
* [opaque pointer type] Bitcode support for explicit type parameter on the gep ↵David Blaikie2015-03-132-7/+16
| | | | | | | | | | | | | | operator This happened to be fairly easy to support backwards compatibility based on the number of operands (old format had an even number, new format has one more operand so an odd number). test/Bitcode/old-aliases.ll already appears to test old gep operators (if I remove the backwards compatibility in the BitcodeReader, this and another test fail) so I'm not adding extra test coverage here. llvm-svn: 232216
* Turn assertion into bitcode reading errorDavid Blaikie2015-03-131-2/+2
| | | | | | | | I don't think we test invalid bitcode records in any detail, so no test here - just a change for consistency with existing error checks in surrounding code. llvm-svn: 232215
* Add a parameter for getLazyBitcodeModule to lazily load Metadata.Manman Ren2015-03-132-11/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata is true and we have not loaded any Metadata block yet. This commit implements all-or-nothing loading of Metadata. If there is a request to load any metadata block, we will load all deferred metadata blocks. We make sure the deferred metadata blocks are loaded before we materialize any function or a module. The default value of the added parameter ShouldLazyLoadMetadata for getLazyBitcodeModule is false, so the default behavior stays the same. We only set the parameter to true when creating LTOModule in local contexts. These can only really be used for parsing symbols, so it's unnecessary to ever load the metadata blocks. If we are going to enable lazy-loading of Metadata for other usages of getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can expose BitcodeReader::materializeMetadata to Module, similar to Module::materialize. rdar://19804575 llvm-svn: 232198
* Simplify expressions involving boolean constants with clang-tidyDavid Blaikie2015-03-091-1/+1
| | | | | | | | Patch by Richard (legalize at xmission dot com). Differential Revision: http://reviews.llvm.org/D8154 llvm-svn: 231617
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* Silence three more variable set but not used warnings, NFC.Yaron Keren2015-02-281-0/+3
| | | | llvm-svn: 230853
* [opaque pointer type] Bitcode support for explicit type parameter on GEP.David Blaikie2015-02-252-7/+37
| | | | | | | | | | | | | | | | | | | Like r230414, add bitcode support including backwards compatibility, for an explicit type parameter to GEP. At the suggestion of Duncan I tried coalescing the two older bitcodes into a single new bitcode, though I did hit a wrinkle: I couldn't figure out how to create an explicit abbreviation for a record with a variable number of arguments (the indicies to the gep). This means the discriminator between inbounds and non-inbounds gep is a full variable-length field I believe? Is my understanding correct? Is there a way to create such an abbreviation? Should I just use two bitcodes as before? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7736 llvm-svn: 230415
* [opaque pointer type] bitcode support for explicit type parameter to the ↵David Blaikie2015-02-252-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | load instruction Summary: I've taken my best guess at this, but I've cargo culted in places & so explanations/corrections would be great. This seems to pass all the tests (check-all, covering clang and llvm) so I believe that pretty well exercises both the backwards compatibility and common (same version) compatibility given the number of checked in bitcode files we already have. Is that a reasonable approach to testing here? Would some more explicit tests be desired? 1) is this the right way to do back-compat in this case (looking at the number of entries in the bitcode record to disambiguate between the old schema and the new?) 2) I don't quite understand the logarithm logic to choose the encoding type of the type parameter in the abbreviation description, but I found another instruction doing the same thing & it seems to work. Is that the right approach? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7655 llvm-svn: 230414
* BitcodeWriter: Refactor common computation of bits required for a type index.David Blaikie2015-02-253-4/+9
| | | | | | Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
* Use common parse routine to read alignment values from bitcodeJF Bastien2015-02-222-14/+46
| | | | | | | | | | While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem. This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic. Patch by Karl Schimpf (kschimpf@google.com). llvm-svn: 230180
* Bitcode: Stop assuming non-null fieldsDuncan P. N. Exon Smith2015-02-202-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When writing the bitcode serialization for the new debug info hierarchy, I assumed two fields would never be null. Drop that assumption, since it's brittle (and crashes the `BitcodeWriter` if wrong), and is a check better left for the verifier anyway. (No need for a bitcode upgrade here, since the new hierarchy is still not in place.) The fields in question are `MDCompileUnit::getFile()` and `MDDerivedType::getBaseType()`, the latter of which isn't null in test/Transforms/Mem2Reg/ConvertDebugInfo2.ll (see !14, a pointer to nothing). While the testcase might have bitrotted, there's no reason for the bitcode format to rely on non-null for metadata operands. This also fixes a bug in `AsmWriter` where if the `file:` is null it isn't emitted (caught by the double-round trip in the testcase I'm adding) -- this is a required field in `LLParser`. I'll circle back to ConvertDebugInfo2. Once the specialized nodes are in place, I'll be trying to turn the debug info verifier back on by default (in the newer module pass form committed r206300) and throwing more logic in there. If the testcase has bitrotted (as opposed to me not understanding the schema correctly) I'll fix it then. llvm-svn: 229960
* IR: Drop scope from MDTemplateParameterDuncan P. N. Exon Smith2015-02-192-12/+9
| | | | | | | | | | Follow-up to r229740, which removed `DITemplate*::getContext()` after my upgrade script revealed that scopes are always `nullptr` for template parameters. This is the other shoe: drop `scope:` from `MDTemplateParameter` and its two subclasses. (Note: a bitcode upgrade would be pointless, since the hierarchy hasn't been moved into place.) llvm-svn: 229791
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-13/+6
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* Bitcode: Fix major regression: large files w/ debug infoDuncan P. N. Exon Smith2015-02-162-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The metadata/value split introduced a major regression reading large bitcode files that contain debug info (or other cyclic (non-self reference) metadata graphs). For the first time in a while, I dropped from libLTO.dylib down to `llvm-lto` with a non-trivial bitcode file (~350MB), and I hit this when reading the result of ld64's `-save-temps` in `llvm-lto`. Here's pseudo-code for what was going on: read-main-metadata-block: for each md: if has-fwd-ref: // Only true for cyclic graphs. any-fwd-refs <- true if any-fwd-refs: foreach md: resolve-cycles(md) // Handle cycles. foreach function: read-function-metadata-block: // Such as !alias, !loop if any-fwd-refs: foreach md: // (all metadata, not just this block) resolve-cycles(md) // A no-op, but the loop is expensive!! This commit resets the `AnyFwdRefs` flag to `false`. This on its own was enough to change my Release+Asserts `llvm-lto` time for reading this bitcode from over 20 minutes (I gave up on it) to 20 seconds. I've gone further by tracking the min/max metadata forward-references in a metadata block. This protects against a schema that has lots of functions that each reference their own metadata cycle. Unfortunately, this regression is in the 3.6 branch as well. llvm-svn: 229421
* [Bitcode reader] Fix a few assertions when reading invalid filesFilipe Cabecinhas2015-02-161-0/+32
| | | | | | | | | | | | | | | | Summary: When creating {insert,extract}value instructions from a BitcodeReader, we weren't verifying the fields were valid. Bugs found with afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7325 llvm-svn: 229345
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-152-3/+3
| | | | | | requiring the macro. NFC; LLVM edition. llvm-svn: 229340
* Clean up some inappropriate choices of type in the bitcode reader. None ofRichard Smith2015-02-131-1/+1
| | | | | | these are expected to fix any 64->32 bit real truncation issues. llvm-svn: 229153
* AsmWriter/Bitcode: MDImportedEntityDuncan P. N. Exon Smith2015-02-132-4/+26
| | | | llvm-svn: 229025
* AsmWriter/Bitcode: MDObjCPropertyDuncan P. N. Exon Smith2015-02-132-4/+30
| | | | llvm-svn: 229024
* AsmWriter/Bitcode: MDExpressionDuncan P. N. Exon Smith2015-02-132-4/+23
| | | | llvm-svn: 229023
* AsmWriter/Bitcode: MDLocalVariableDuncan P. N. Exon Smith2015-02-132-4/+32
| | | | llvm-svn: 229022
* AsmWriter/Bitcode: MDGlobalVariableDuncan P. N. Exon Smith2015-02-132-4/+34
| | | | llvm-svn: 229020
* AsmWriter/Bitcode: MDTemplate{Type,Value}ParameterDuncan P. N. Exon Smith2015-02-132-12/+51
| | | | llvm-svn: 229019
* AsmWriter/Bitcode: MDNamespaceDuncan P. N. Exon Smith2015-02-132-4/+25
| | | | llvm-svn: 229018
* AsmWriter/Bitcode: MDLexicalBlockFileDuncan P. N. Exon Smith2015-02-132-4/+24
| | | | llvm-svn: 229017
* AsmWriter/Bitcode: MDLexicalBlockDuncan P. N. Exon Smith2015-02-132-4/+25
| | | | llvm-svn: 229016
* AsmWriter/Bitcode: MDSubprogramDuncan P. N. Exon Smith2015-02-132-4/+44
| | | | llvm-svn: 229014
* AsmWriter/Bitcode: MDCompileUnitDuncan P. N. Exon Smith2015-02-132-4/+38
| | | | llvm-svn: 229013
* AsmWriter/Bitcode: MDSubroutineTypeDuncan P. N. Exon Smith2015-02-132-4/+21
| | | | llvm-svn: 229011
* AsmWriter/Bitcode: MDDerivedType and MDCompositeTypeDuncan P. N. Exon Smith2015-02-132-11/+84
| | | | llvm-svn: 229009
* AsmWriter/Bitcode: MDFileDuncan P. N. Exon Smith2015-02-132-4/+21
| | | | llvm-svn: 229007
* AsmWriter/Bitcode: MDBasicTypeDuncan P. N. Exon Smith2015-02-132-4/+25
| | | | llvm-svn: 229005
* AsmWriter/Bitcode: MDEnumeratorDuncan P. N. Exon Smith2015-02-132-4/+21
| | | | llvm-svn: 229004
* AsmWriter/Bitcode: MDSubrangeDuncan P. N. Exon Smith2015-02-132-4/+28
| | | | llvm-svn: 229003
* Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner2015-02-111-0/+3
| | | | | | | | | | This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
* IR: Add specialized debug info metadata nodesDuncan P. N. Exon Smith2015-02-101-0/+100
| | | | | | | | | | | | | | | Add specialized debug info metadata nodes that match the `DIDescriptor` wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to follow soon (it'll mostly just be obvious), but this sketches in today's schema. This is the first big commit (well, the only *big* one aside from the testcase changes that'll come when I move this into place) for PR22464. I've marked a bunch of obvious changes as `TODO`s in the source; I plan to make those changes promptly after this hierarchy is moved underneath `DIDescriptor`, but for now I'm aiming mostly to match the status quo. llvm-svn: 228640
* IR: Initialize MDNode abbreviations en masse, NFCDuncan P. N. Exon Smith2015-02-041-3/+4
| | | | llvm-svn: 228203
* Misc documentation/comment fixes.Peter Collingbourne2015-02-042-2/+4
| | | | llvm-svn: 228093
* IR: Assembly and bitcode for GenericDebugNodeDuncan P. N. Exon Smith2015-02-034-6/+67
| | | | llvm-svn: 228041
* Propagate a better error message to the C api.Rafael Espindola2015-02-031-3/+5
| | | | llvm-svn: 227934
* Use a non-fatal diag handler in the C API. FIxes PR22368.Rafael Espindola2015-02-031-2/+11
| | | | llvm-svn: 227903
* IR: Split out DebugInfoMetadata.h, NFCDuncan P. N. Exon Smith2015-02-023-0/+3
| | | | | | | | | Move debug-info-centred `Metadata` subclasses into their own header/source file. A couple of private template functions are needed from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them to `lib/IR/MetadataImpl.h`. llvm-svn: 227835
* Check bit widths before trying to get a type.Filipe Cabecinhas2015-01-301-2/+7
| | | | | | | | | Added a test case for it. Also added run lines for the test case in r227566. Bugs found with afl-fuzz llvm-svn: 227589
* [bitcode reader] Fix an assert on invalid type tablesFilipe Cabecinhas2015-01-301-1/+3
| | | | | | Bug found with afl-fuzz llvm-svn: 227566
* [Bitcode] Diagnose errors instead of asserting from bad inputFilipe Cabecinhas2015-01-241-1/+5
| | | | | | | | | | | | | | | Eventually we can make some of these pass the error along to the caller. Reports a fatal error if: We find an invalid abbrev record We try to get an invalid abbrev number We can't fill the current word due to an EOF Fixed an invalid bitcode test to check for output with FileCheck Bugs found with afl-fuzz llvm-svn: 226986
OpenPOWER on IntegriCloud