summaryrefslogtreecommitdiffstats
path: root/llvm/test/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* [Bitcode] Diagnose errors instead of asserting from bad inputFilipe Cabecinhas2015-01-244-1/+15
| | | | | | | | | | | | | | | 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
* Bitcode: Don't create comdats when autoupgrading macho bitcodeDavid Majnemer2015-01-202-0/+11
| | | | | | | Don't infer COMDAT groups from older bitcode if the target is macho, it doesn't have COMDATs. llvm-svn: 226546
* Bring r226038 back.Rafael Espindola2015-01-191-6/+6
| | | | | | | | | | | | | | | | No change in this commit, but clang was changed to also produce trivial comdats when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226467
* Revert r226242 - Revert Revert Don't create new comdats in CodeGenTimur Iskhodzhanov2015-01-161-6/+6
| | | | | | This breaks AddressSanitizer (ninja check-asan) on Windows llvm-svn: 226251
* Use report_fatal_error instead of llvm_unreachable, so we don't crash on ↵Filipe Cabecinhas2015-01-162-0/+1
| | | | | | user input llvm-svn: 226248
* Revert "Revert Don't create new comdats in CodeGen"Rafael Espindola2015-01-161-6/+6
| | | | | | | | | | | | | | | | | | This reverts commit r226173, adding r226038 back. No change in this commit, but clang was changed to also produce trivial comdats for costructors, destructors and vtables when needed. Original message: Don't create new comdats in CodeGen. This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226242
* Revert Don't create new comdats in CodeGenTimur Iskhodzhanov2015-01-151-6/+6
| | | | | | It breaks AddressSanitizer on Windows. llvm-svn: 226173
* IR: Move MDLocation into placeDuncan P. N. Exon Smith2015-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | This commit moves `MDLocation`, finishing off PR21433. There's an accompanying clang commit for frontend testcases. I'll attach the testcase upgrade script I used to PR21433 to help out-of-tree frontends/backends. This changes the schema for `DebugLoc` and `DILocation` from: !{i32 3, i32 7, !7, !8} to: !MDLocation(line: 3, column: 7, scope: !7, inlinedAt: !8) Note that empty fields (line/column: 0 and inlinedAt: null) don't get printed by the assembly writer. llvm-svn: 226048
* Don't create new comdats in CodeGen.Rafael Espindola2015-01-141-6/+6
| | | | | | | | | This patch stops the implicit creation of comdats during codegen. Clang now sets the comdat explicitly when it is required. With this patch clang and gcc now produce the same result in pr19848. llvm-svn: 226038
* Use the DiagnosticHandler to print diagnostics when reading bitcode.Rafael Espindola2015-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
* Make this test a bit stricter.Rafael Espindola2015-01-081-41/+41
| | | | | | | It now checks for the end of the line or the opening '{'. While at it, remove empty comments. llvm-svn: 225451
* IR: Make metadata typeless in assemblyDuncan P. N. Exon Smith2014-12-159-36/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
* Bitcode: Use unsigned char to record MDStringsDuncan P. N. Exon Smith2014-12-111-0/+9
| | | | | | | | | | `MDString`s can have arbitrary characters in them. Prevent an assertion that fired in `BitcodeWriter` because of sign extension by copying the characters into the record as `unsigned char`s. Based on a patch by Keno Fischer; fixes PR21882. llvm-svn: 224077
* Bitcode: Add METADATA_NODE and METADATA_VALUEDuncan P. N. Exon Smith2014-12-112-0/+26
| | | | | | | | | | | | | | | | This reflects the typelessness of `Metadata` in the bitcode format, removing types from all metadata operands. `METADATA_VALUE` represents a `ValueAsMetadata`, and always has two fields: the type and the value. `METADATA_NODE` represents an `MDNode`, and unlike `METADATA_OLD_NODE`, doesn't store types. It stores operands at their ID+1 so that `0` can reference `nullptr` operands. Part of PR21532. llvm-svn: 224073
* IR: Fix bitcode compatability filenamesDuncan P. N. Exon Smith2014-12-082-0/+0
| | | | | | | As a fixup to r223616, follow the convention of naming the files after the LLVM release whose bitcode they're maintaining compatability with. llvm-svn: 223623
* IR: Add missing tests for function-local metadataDuncan P. N. Exon Smith2014-12-072-0/+35
| | | | | | | | | | | | | | | | | | | | | | | Add assembly and bitcode tests that I neglected to add in r223564 (IR: Disallow complicated function-local metadata) and r223574 (IR: Disallow function-local metadata attachments). Found a couple of bugs: - The error message for function-local attachments gave the wrong line number -- it indicated the next token (typically on the next line) instead of the token that started the attachment. Fixed. - Metadata arguments of the form `!{i32 0, i32 %v}` (or with the arguments reversed) fired an assertion in `ValueEnumerator` in LLVM v3.5, so I suppose this never really worked. I suppose this was "fixed" by r223564. (Thanks to dblaikie for pointing out my omission.) Part of PR21532. llvm-svn: 223616
* Parse 'ghccc' in .ll files as the GHC convention (cc 10)Reid Kleckner2014-12-011-2/+2
| | | | | | | Previously we just used "cc 10" in the .ll files, but that isn't very human readable. llvm-svn: 223076
* Revert "Revert "DI: Fold constant arguments into a single MDString""Duncan P. N. Exon Smith2014-10-031-5/+5
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
* Revert "DI: Fold constant arguments into a single MDString"Duncan P. N. Exon Smith2014-10-021-5/+5
| | | | | | This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
* DI: Fold constant arguments into a single MDStringDuncan P. N. Exon Smith2014-10-021-5/+5
| | | | | | | | | | | | | This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 218914
* Ensure bitcode encoding stays stable.Michael Kuperstein2014-09-2312-56/+388
| | | | | | | | This includes constants, attributes, and some additional instructions not covered by previous tests. Work was done by lama.saba@intel.com. llvm-svn: 218297
* Teach llvm-bcanalyzer to use one stream's BLOCKINFO to read another stream.Jordan Rose2014-08-301-0/+2
| | | | | | | | | | | This allows streams that only use BLOCKINFO for debugging purposes to omit the block entirely. As long as another stream is available with the correct BLOCKINFO, the first stream can still be analyzed and dumped. As part of this commit, BitstreamReader gets a move constructor and move assignment operator, as well as a takeBlockInfo method. llvm-svn: 216826
* verify-uselistorder: Force -preserve-bc-use-list-orderDuncan P. N. Exon Smith2014-08-1943-43/+43
| | | | llvm-svn: 216022
* verify-uselistorder: Call verifyModule() and improve outputDuncan P. N. Exon Smith2014-08-181-2/+2
| | | | | | | | Call `verifyModule()` after parsing and after every transformation. Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility into what's going on. llvm-svn: 215951
* BitcodeReader: Only create one basic block for each blockaddressDuncan P. N. Exon Smith2014-08-161-0/+14
| | | | | | | | | | | | | | | | Block address forward-references are implemented by creating a `BasicBlock` ahead of time that gets inserted in the `Function` when it's eventually encountered. However, if the same blockaddress was used in two separate functions that were parsed *before* the referenced function (and the blockaddress was never used at global scope), two separate basic blocks would get created, one of which would be forgotten creating invalid IR. This commit changes the forward-reference logic to create only one basic block (and always return the same blockaddress). llvm-svn: 215805
* Don't upgrade global constructors when reading bitcodeDuncan P. N. Exon Smith2014-08-122-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An optional third field was added to `llvm.global_ctors` (and `llvm.global_dtors`) in r209015. Most of the code has been changed to deal with both versions of the variables. Users of the C API might create either version, the helper functions in LLVM create the two-field version, and clang now creates the three-field version. However, the BitcodeReader was changed to always upgrade to the three-field version. This created an unnecessary inconsistency in the IR before/after serializing to bitcode. This commit resolves the inconsistency by making the third field truly optional (and not upgrading in the bitcode reader). Since `llvm-link` was relying on this upgrade code, rather than deleting it I've moved it into `ModuleLinker`, where it upgrades these arrays as necessary to resolve inconsistencies between modules. The ideal resolution would be to remove the 2-field version and make the third field required. I filed PR20506 to track that. I changed `test/Bitcode/upgrade-global-ctors.ll` to a negative test and duplicated the `llvm-link` check in `test/Linker/global_ctors.ll` to check both upgrade directions. Since I came across this as part of PR5680 (serializing use-list order), I've also added the missing `verify-uselistorder` RUN line to `test/Bitcode/metadata-2.ll`. llvm-svn: 215457
* UseListOrder: Fix blockaddress use-list orderDuncan P. N. Exon Smith2014-08-012-0/+36
| | | | | | | | | | | | | | | | | | | `parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as a helper. Since `parseBitcodeFile()` isn't actually lazy -- it calls `MaterializeAllPermanently()` -- bypass the unnecessary call to `materializeForwardReferencedFunctions()` by extracting out a common helper function. This removes the last of the use-list churn caused by blockaddresses. This highlights that we can't reproduce use-list order of globals and constants when parsing lazily -- but that's necessarily out of scope. When we're parsing lazily, we never have all the functions in memory, so the use-lists of globals (and constants that reference globals) are always incomplete. This is part of PR5680. llvm-svn: 214581
* verify-uselistorder: Change the default -num-shuffles=5Duncan P. N. Exon Smith2014-07-3141-41/+41
| | | | | | | Change the default for `-num-shuffles` to 5 and better document the algorithm in the header docs of `verify-uselistorder`. llvm-svn: 214419
* UseListOrder: Handle self-usersDuncan P. N. Exon Smith2014-07-311-0/+13
| | | | | | | | | | Correctly sort self-users (such as PHI nodes). I added a targeted test in `test/Bitcode/use-list-order.ll` and the final missing RUN line to tests in `test/Assembly`. This is part of PR5680. llvm-svn: 214417
* UseListOrder: Don't give constant IDs to GlobalValuesDuncan P. N. Exon Smith2014-07-311-0/+13
| | | | | | | | | | | Since initializers of GlobalValues are being assigned IDs before GlobalValues themselves, explicitly exclude GlobalValues from the constant pool. Added targeted test in `test/Bitcode/use-list-order.ll` and added two more RUN lines in `test/Assembly`. This is part of PR5680. llvm-svn: 214368
* Use "weak alias" instead of "alias weak"Rafael Espindola2014-07-301-6/+6
| | | | | | | | | | | | | | | | | | | | | Before this patch we had @a = weak global ... but @b = alias weak ... The patch changes aliases to look more like global variables. Looking at some really old code suggests that the reason was that the old bison based parser had a reduction for alias linkages and another one for global variable linkages. Putting the alias first avoided the reduce/reduce conflict. The days of the old .ll parser are long gone. The new one parses just "linkage" and a later check is responsible for deciding if a linkage is valid in a given context. llvm-svn: 214355
* UseListOrder: Visit global valuesDuncan P. N. Exon Smith2014-07-304-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When predicting use-list order, we visit functions in reverse order followed by `GlobalValue`s and write out use-lists at the first opportunity. In the reader, this will translate to *after* the last use has been added. For this to work, we actually need to descend into `GlobalValue`s. Added a targeted test in `use-list-order.ll` and `RUN` lines to the newly passing tests in `test/Bitcode`. There are two remaining failures in `test/Bitcode`: - blockaddress.ll: I haven't thought through how to model the way block addresses change the order of use-lists (or how to work around it). - metadata-2.ll: There's an old-style `@llvm.used` global array here that I suspect the .ll parser isn't upgrading properly. When it round-trips through bitcode, the .bc reader *does* upgrade it, so the extra variable (`i8* null`) has an extra use, and the shuffle vector doesn't match. I think the fix is to upgrade old-style global arrays (or reject them?) in the .ll parser. This is part of PR5680. llvm-svn: 214321
* Fix line endings before adding RUN lines, NFCDuncan P. N. Exon Smith2014-07-302-159/+159
| | | | llvm-svn: 214320
* Rename llvm-uselistorder => verify-uselistorderDuncan P. N. Exon Smith2014-07-3038-38/+38
| | | | llvm-svn: 214318
* Reapply "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-303-0/+16
| | | | | | | This reverts commit r214249, reapplying r214242 and r214243, now that r214270 has fixed the UB. llvm-svn: 214271
* Revert "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-293-16/+0
| | | | | | | | | | | | This reverts commits r214242 and r214243 while I investigate buildbot failures [1][2][3]. I can't reproduce these failures locally, so if anyone can see what I've done wrong, I'd appreciate a note. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9840 [2]: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/14981 [3]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/15191 llvm-svn: 214249
* UseListOrder: Additional test coverage for r214242Duncan P. N. Exon Smith2014-07-291-0/+14
| | | | | | | | r214242 was subtle enough it really deserves a targeted test with comments. This adds some global variables that trigger the relevant code path. Sorry this wasn't committed with the fix. llvm-svn: 214243
* UseListOrder: Order GlobalValue uses after initializersDuncan P. N. Exon Smith2014-07-292-0/+2
| | | | | | | | | | | | To avoid unnecessary forward references, the reader doesn't process initializers of `GlobalValue`s until after the constant pool has been processed, and then in reverse order. Model this when predicting use-list order. This gets two more Bitcode tests passing with `llvm-uselistorder`. Part of PR5680. llvm-svn: 214242
* Bitcode: Correctly compare a Use against itselfDuncan P. N. Exon Smith2014-07-2935-0/+35
| | | | | | | | | | | | | | | Fix the sort of expected order in the reader to correctly return `false` when comparing a `Use` against itself. This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm adding a `RUN` line using `llvm-uselistorder` for every test in `test/Bitcode` that passes. A few tests still fail, so I'll investigate those next. This is part of PR5680. llvm-svn: 214157
* Fix line-endings, NFCDuncan P. N. Exon Smith2014-07-2910-913/+911
| | | | | | | A follow-up commit is adding a RUN line to each of these tests, so fix the line endings first. This is a whitespace-only change. llvm-svn: 214156
* llvm-uselistorder: Add -num-shuffles optionDuncan P. N. Exon Smith2014-07-281-1/+1
| | | | llvm-svn: 214144
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
* Move -verify-use-list-order into llvm-uselistorderDuncan P. N. Exon Smith2014-07-251-1/+1
| | | | | | | | | | | | | | | | | Ugh. Turns out not even transformation passes link in how to read IR. I sincerely believe the buildbots will finally agree with my system after this though. (I don't really understand why all of this has been working on my system, but not on all the buildbots.) Create a new tool called llvm-uselistorder to use for verifying use-list order. For now, just dump everything from the (now defunct) -verify-use-list-order pass into the tool. This might be a better way to test use-list order anyway. Part of PR5680. llvm-svn: 213957
* IPO: Add use-list-order verifierDuncan P. N. Exon Smith2014-07-251-0/+83
| | | | | | | | | | | | | | | | | | | | Add a -verify-use-list-order pass, which shuffles use-list order, writes to bitcode, reads back, and verifies that the (shuffled) order matches. - The utility functions live in lib/IR/UseListOrder.cpp. - Moved (and renamed) the command-line option to enable writing use-lists, so that this pass can return early if the use-list orders aren't being serialized. It's not clear that this pass is the right direction long-term (perhaps a separate tool instead?), but short-term it's a great way to test the use-list order prototype. I've added an XFAIL-ed testcase that I'm hoping to get working pretty quickly. This is part of PR5680. llvm-svn: 213945
* AsmParser: remove deprecated LLIR supportSaleem Abdulrasool2014-07-231-17/+0
| | | | | | | linker_private and linker_private_weak were deprecated in 3.5. Remove support for them now that the 3.5 branch has been created. llvm-svn: 213777
* Make use of the align parameter attribute for all pointer argumentsHal Finkel2014-07-221-0/+5
| | | | | | | | | | | | | | | | | | | | We previously supported the align attribute on all (pointer) parameters, but we only used it for byval parameters. However, it is completely consistent at the IR level to treat 'align n' on all pointer parameters as an alignment assumption on the pointer, and now we wll. Specifically, this causes computeKnownBits to use the align attribute on all pointer parameters, not just byval parameters. I've also added an explicit parameter attribute test for this to test/Bitcode/attributes.ll. And I've updated the LangRef to document the align parameter attribute (as it turns out, it was not documented at all previously, although the byval documentation mentioned that it could be used). There are (at least) two benefits to doing this: - It allows enhancing alignment based on the pointer alignment after inlining callees. - It allows simplification of pointer arithmetic. llvm-svn: 213670
* Rename metadata llvm.loop.vectorize.unroll to llvm.loop.vectorize.interleave.Mark Heffernan2014-07-211-1/+1
| | | | llvm-svn: 213588
* Add a dereferenceable attributeHal Finkel2014-07-181-0/+10
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Roundtrip the inalloca bit on allocas through bitcodeReid Kleckner2014-07-161-0/+18
| | | | | | | | | | | | | This was an oversight in the original support. As it is, I stuffed this bit into the alignment. The alignment is stored in log2 form, so it doesn't need more than 5 bits, given that Value::MaximumAlignment is 1 << 29. Reviewers: nicholas Differential Revision: http://reviews.llvm.org/D3943 llvm-svn: 213118
* Add some test files for r211710.Eli Bendersky2014-06-252-0/+37
| | | | llvm-svn: 211711
OpenPOWER on IntegriCloud