summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Bitcode][Asm] Teach LLVM to read and write operand bundles.Sanjoy Das2015-09-241-2/+80
| | | | | | | | | | | | | | | | | | Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
* Silencing a -Wsign-compare warning; NFC.Aaron Ballman2015-09-181-1/+1
| | | | llvm-svn: 247986
* [opaque pointer types] Add an explicit pointee type to alias records in the IRDavid Blaikie2015-09-171-23/+39
| | | | | | | | | | Since aliases actually use and verify their explicit type already, no further invalid testing is required here. The invalid.test:ALIAS-TYPE-MISMATCH case catches errors due to emitting a non-pointee type in the new format or a non-pointer type in the old format. llvm-svn: 247952
* Restore "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-171-21/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r247898 (which reverted r247894). Patch fixed to address two issues exposed by buildbots: - unused variable warning in NDEBUG mode - std::initializer_list lifetime issue causing test failures Original Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247927
* Revert "Function bitcode index in Value Symbol Table and lazy reading support"Teresa Johnson2015-09-171-147/+21
| | | | | | | | | | Temporarily revert to fix some buildbot issues. One is a minor issue with a variable unused in NDEBUG mode. More concerning are some test failures on win7 that I need to dig into. This reverts commit 4e66a74543459832cfd571db42b4543580ae1d1d. llvm-svn: 247898
* Function bitcode index in Value Symbol Table and lazy reading supportTeresa Johnson2015-09-171-21/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for including the function bitcode indices in the Value Symbol Table. This requires writing the VST after the function blocks, which in turn requires a new VST forward declaration record encoding the offset of the full VST (which is backpatched to contain the offset after the VST is written). This patch also enables the lazy function reader to use the new function indices out of the VST. This support will be used by ThinLTO as well, which will be in a follow on patch. Backwards compatibility with older bitcode files is maintained. A new test is also included. The bitcode format (used for the lazy reader as well as the upcoming ThinLTO patches) came out of discussions with Duncan and others and is described here: https://drive.google.com/file/d/0B036uwnWM6RWdnBLakxmeDdOeXc/view Reviewers: dexonsmith, davidxl, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12536 llvm-svn: 247894
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-1/+2
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-0/+19
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [BitcodeReader] Ensure we can read constant vector selects with an i1 conditionFilipe Cabecinhas2015-08-311-4/+5
| | | | | | | | | | | | | | | Summary: Constant vectors weren't allowed to have an i1 condition in the BitcodeReader. Make sure we have the same restrictions that are documented, not more. Reviewers: nlewycky, rafael, kschimpf Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12440 llvm-svn: 246459
* Change comment to verify commit accesss.Karl Schimpf2015-08-311-1/+1
| | | | llvm-svn: 246451
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* [IR] Cleanup EH instructions a little bitDavid Majnemer2015-08-231-2/+1
| | | | | | Just a cosmetic change, no functionality change is intended. llvm-svn: 245818
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-54/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
* [IR] Give catchret an optional 'return value' operandDavid Majnemer2015-08-151-3/+9
| | | | | | | | | | | Some personality routines require funclet exit points to be clearly marked, this is done by producing a token at the funclet pad and consuming it at the corresponding ret instruction. CleanupReturnInst already had a spot for this operand but CatchReturnInst did not. Other personality routines don't need to use this which is why it has been made optional. llvm-svn: 245149
* [IR] Add token typesDavid Majnemer2015-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-8/+9
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-311-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags, using `DW_TAG_variable` in their place Stop exposing the `tag:` field at all in the assembly format for `DILocalVariable`. Most of the testcase updates were generated by the following sed script: find test/ -name "*.ll" -o -name "*.mir" | xargs grep -l 'DILocalVariable' | xargs sed -i '' \ -e 's/tag: DW_TAG_arg_variable, //' \ -e 's/tag: DW_TAG_auto_variable, //' There were only a handful of tests in `test/Assembly` that I needed to update by hand. (Note: a follow-up could change `DILocalVariable::DILocalVariable()` to set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable` (as appropriate), instead of having that logic magically in the backend in `DbgVariable`. I've added a FIXME to that effect.) llvm-svn: 243774
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+128
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* Reserve some constant values for the Swift calling convention.Bob Wilson2015-07-281-0/+2
| | | | | | | | | | | Swift has a custom calling convention that also requires some new flags on arguments and one new attribute on alloca instructions. This patch does not include the implementation of that calling convention - that will be provided as part of the open-source release of Swift; this only reserves the bitcode constant values so that they are not used for other purposes. llvm-svn: 243379
* Add argmemonly attribute.Igor Laevsky2015-07-111-0/+2
| | | | | | | | This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
* Add support for fast-math flags to the FCmp instruction.James Molloy2015-07-101-15/+31
| | | | | | | | | | | | | | FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
* Revert the new EH instructionsDavid Majnemer2015-07-101-128/+0
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-0/+128
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* Remove always-true comparison, NFC.Filipe Cabecinhas2015-07-031-16/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: Looking at r241279, I noticed that UpgradedIntrinsics only gets written to in the following code: if (UpgradeIntrinsicFunction(&F, NewFn)) UpgradedIntrinsics[&F] = NewFn; Looking through UpgradeIntrinsicFunction, we always return false OR NewFn will be set to a different function from our source. This patch pulls the F != NewFn into UpgradeIntrinsicFunction as an assert, and removes the check from callers of UpgradeIntrinsicFunction. Reviewers: rafael, chandlerc Subscribers: llvm-commits-list Differential Revision: http://reviews.llvm.org/D10915 llvm-svn: 241369
* Avoid a use after free.Rafael Espindola2015-07-031-1/+4
| | | | llvm-svn: 241345
* Fix for PR23310: llvm-dis crashes when trying to upgrade an intrinsic.Rafael Espindola2015-07-021-3/+3
| | | | | | | | | | | | When trying to upgrade @llvm.x86.sse2.psrl.dq while parsing a module, BitcodeReader adds the function to its worklist twice, resulting in a crash when accessing it the second time. This patch replaces the worklist vector by a map. Patch by Philip Pfaffe. llvm-svn: 241281
* Rangify some loops.Rafael Espindola2015-07-021-17/+13
| | | | | | Patch by Philip Pfaffe! llvm-svn: 241279
* Add a DIModule metadata node to the IR.Adrian Prantl2015-06-291-0/+14
| | | | | | | | | | | | | | | | | | | It is meant to be used to record modules @imported by the current compile unit, so a debugger an import the same modules to replicate this environment before dropping into the expression evaluator. DIModule is a sibling to DINamespace and behaves quite similarly. In addition to the name of the module it also records the module configuration details that are necessary to uniquely identify the module. This includes the configuration macros (e.g., -DNDEBUG), the include path where the module.map file is to be found, and the isysroot. The idea is that the backend will turn this into a DW_TAG_module. http://reviews.llvm.org/D9614 rdar://problem/20965932 llvm-svn: 241017
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-3/+3
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Remove the IsStreamed member variable.Rafael Espindola2015-06-221-15/+9
| | | | | | | | | | | | | | | | | | Having different code paths for streamed and regular bitcode reading was a source of bugs in the past and this defines them away. It has a small but noticeable impact on performance. I timed running "opt -disable-output -disable-verify" on a ltoed clang. It goes from 14.752845231 seconds time elapsed ( +- 0.16% ) to 15.012463721 seconds time elapsed ( +- 0.11% ) Extracted from a patch by Karl Schimpf. llvm-svn: 240305
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-3/+3
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-7/+40
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Handle forward referenced function when streaming bitcode.Rafael Espindola2015-06-171-24/+35
| | | | | | | | Without this the included unit test would assert in assert(BasicBlockFwdRefs.empty() && "Unresolved blockaddress fwd references"); llvm-svn: 239871
* Handle MaterializeAll in getLazyBitcodeModuleImpl. NFC.Rafael Espindola2015-06-171-15/+11
| | | | | | | | This just handles both cases in the same place. Extracted from a patch by Karl Schimpf. llvm-svn: 239870
* Use std::unique_ptr to manage the DataStreamer in bitcode parsing.Rafael Espindola2015-06-161-26/+31
| | | | | | We were already deleting it, this just makes it explicit. llvm-svn: 239867
* Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.Rafael Espindola2015-06-161-17/+13
| | | | llvm-svn: 239858
* Improve handling of end of file in the bitcode reader.Rafael Espindola2015-06-161-40/+5
| | | | | | | | | | | | | | | | | | | | | | Before this patch the bitcode reader would read a module from a file that contained in order: * Any number of non MODULE_BLOCK sub blocks. * One MODULE_BLOCK * Any number of non MODULE_BLOCK sub blocks. * 4 '\n' characters to handle OS X's ranlib. Since we support lazy reading of modules, any information that is relevant for the module has to be in the MODULE_BLOCK or before it. We don't gain anything from checking what is after. This patch then changes the reader to stop once the MODULE_BLOCK has been successfully parsed. This avoids the ugly special case for .bc files in an archive and makes it easier to embed bitcode files. llvm-svn: 239845
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* Don't indent inside a namespace. NFC.Rafael Espindola2015-06-151-21/+19
| | | | llvm-svn: 239760
* Replace @ with the more common \. NFC.Rafael Espindola2015-06-151-6/+6
| | | | llvm-svn: 239759
* Don't repeat names in comments and start functions with a lower case letter.Rafael Espindola2015-06-151-537/+527
| | | | llvm-svn: 239756
* Cleanup the constructor of BitcodeReader. NFC.Rafael Espindola2015-06-151-30/+28
| | | | | | | | | Use the same argument names as the members. Use default member initializes. Extracted from a patch by Karl Schimpf. llvm-svn: 239749
* Rangify two for loops in BitcodeReader.cpp.Yaron Keren2015-06-121-10/+5
| | | | llvm-svn: 239627
* Use early return idiom. NFCFilipe Cabecinhas2015-06-061-6/+6
| | | | llvm-svn: 239228
* [BitcodeReader] Diagnose type mismatches with aliasesFilipe Cabecinhas2015-06-031-3/+6
| | | | | | Bug found with AFL fuzz. llvm-svn: 238895
* [BitcodeReader] Check vector size before trying to create a VectorTypeFilipe Cabecinhas2015-06-031-0/+2
| | | | | | Bug found with AFL fuzz llvm-svn: 238891
* [BitcodeReader] Change an assert to a call to a call to Error()Filipe Cabecinhas2015-05-301-2/+2
| | | | | | | | It's reachable from user input. Bug found with AFL fuzz. llvm-svn: 238633
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-3/+1
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* [BitcodeReader] Change assert to report_fatal_errorFilipe Cabecinhas2015-05-271-1/+2
| | | | | | | | It can be triggered by user input. Bug found with AFL fuzz. llvm-svn: 238272
* Add initial support for the convergent attribute.Owen Anderson2015-05-261-0/+2
| | | | llvm-svn: 238264
OpenPOWER on IntegriCloud