summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* BitcodeReader: Fix some BlockAddress forward reference corner casesDuncan P. N. Exon Smith2014-08-012-9/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | `BlockAddress`es are interesting in that they can reference basic blocks from *outside* the block's function. Since basic blocks are not global values, this presents particular challenges for lazy parsing. One corner case was found in PR11677 and fixed in r147425. In that case, a global variable references a block address. It's necessary to load the relevant function to resolve the forward reference before doing anything with the module. By inspection, I found (and have fixed here) two other cases: - An instruction from one function references a block address from another function, and only the first function is lazily loaded. I fixed this the same way as PR11677: by eagerly loading the referenced function. - A function whose block address is taken is dematerialized, leaving invalid references to it. I fixed this by refusing to dematerialize functions whose block addresses are taken (if you have to load it, you can't unload it). llvm-svn: 214559
* UseListOrder: Handle self-usersDuncan P. N. Exon Smith2014-07-311-3/+3
| | | | | | | | | | 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-3/+6
| | | | | | | | | | | 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
* UseListOrder: Visit global valuesDuncan P. N. Exon Smith2014-07-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reapply "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-301-14/+55
| | | | | | | This reverts commit r214249, reapplying r214242 and r214243, now that r214270 has fixed the UB. llvm-svn: 214271
* UseListOrder: Fix undefined behaviourDuncan P. N. Exon Smith2014-07-301-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes undefined behaviour that caused the revert in r214249. The problem was two unsequenced operations on a `DenseMap<>`, giving different behaviour in GCC and Clang. This: DenseMap<T*, unsigned> DM; for (auto &X : ...) DM[&X] = DM.size() + 1; should have been: DenseMap<T*, unsigned> DM; for (auto &X : ...) { unsigned Size = DM.size(); DM[&X] = Size + 1; } Until r214242, this difference between compilers didn't matter. In r214242, `OrderMap::LastGlobalValueID` was introduced and compared against IDs, which in GCC were off-by-one my expectations. llvm-svn: 214270
* Revert "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-291-55/+14
| | | | | | | | | | | | 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: Order GlobalValue uses after initializersDuncan P. N. Exon Smith2014-07-291-14/+55
| | | | | | | | | | | | 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
* UseListOrder: Create a struct around OrderMap, NFCDuncan P. N. Exon Smith2014-07-291-1/+9
| | | | llvm-svn: 214241
* Have a single enum for "not a bitcode" error.Rafael Espindola2014-07-291-9/+3
| | | | | | | This is more convenient for callers. No functionality change, this will be used in a next patch to the gold plugin. llvm-svn: 214218
* Move the bitcode error enum to the include directory.Rafael Espindola2014-07-292-276/+248
| | | | | | | | This will let users in other libraries know which error occurred. In particular, it will be possible to check if the parsing failed or if the file is not bitcode. llvm-svn: 214209
* IR: Create the use-list order shuffle vector in-placeDuncan P. N. Exon Smith2014-07-291-4/+3
| | | | | | | Per David Blaikie's review of r214135, this is a more natural way to initialize. llvm-svn: 214184
* Bitcode: Correctly compare a Use against itselfDuncan P. N. Exon Smith2014-07-291-0/+3
| | | | | | | | | | | | | | | 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
* IR: Optimize size of use-list order shuffle vectorsDuncan P. N. Exon Smith2014-07-281-6/+5
| | | | | | | | | Since we're storing lots of these, save two-pointers per vector with a custom type rather than using the relatively heavy `SmallVector`. Part of PR5680. llvm-svn: 214135
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-285-101/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bitcode: Don't optimize constants when preserving use-list orderDuncan P. N. Exon Smith2014-07-251-0/+6
| | | | | | | | | | | | | | | | | | | | `ValueEnumerator::OptimizeConstants()` creates forward references within the constant pools, which makes predicting constants' use-list order difficult. For now, just disable the optimization. This can be re-enabled in the future in one of two ways: - Enable a limited version of this optimization that doesn't create forward references. One idea is to categorize constants by their "height" and make that the top-level sort. - Enable it entirely. This requires predicting how may times each constant will be recreated as its operands' and operands' operands' (etc.) forward references get resolved. This is part of PR5680. llvm-svn: 213953
* IPO: Add use-list-order verifierDuncan P. N. Exon Smith2014-07-251-7/+2
| | | | | | | | | | | | | | | | | | | | 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
* Add a dereferenceable attributeHal Finkel2014-07-182-1/+7
| | | | | | | | | 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
* Rename AlignAttribute to IntAttributeHal Finkel2014-07-182-2/+2
| | | | | | | | | | | | Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
* Roundtrip the inalloca bit on allocas through bitcodeReid Kleckner2014-07-162-4/+15
| | | | | | | | | | | | | 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
* Fix a bug in the conversion to ErrorOr.Rafael Espindola2014-07-041-2/+2
| | | | | | | | | The regular end of the bitcode parsing is in the BitstreamEntry::EndBlock case. Should fix the LTO bootstrap on OS X (this function is only used by ld64). llvm-svn: 212357
* Revert "Convert a few std::strings to StringRef."Rafael Espindola2014-07-042-25/+13
| | | | | | | | | This reverts commit r212342. We can get a StringRef into the current Record, but not one in the bitcode itself since the string is compressed in it. llvm-svn: 212356
* Convert a few std::strings to StringRef.Rafael Espindola2014-07-042-13/+25
| | | | llvm-svn: 212342
* Convert these functions to use ErrorOr.Rafael Espindola2014-07-042-10/+11
| | | | llvm-svn: 212341
* Remove unused old-style error handling.Rafael Espindola2014-07-041-5/+2
| | | | | | If needed, an ErrorOr should be used. llvm-svn: 212340
* IR: Add COMDATs to the IRDavid Majnemer2014-06-275-1/+99
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
* IRReader: don't mark MemoryBuffers constAlp Toker2014-06-271-3/+2
| | | | llvm-svn: 211883
* Propagate const-correctness into parseBitcodeFile()Alp Toker2014-06-271-2/+3
| | | | llvm-svn: 211864
* Rename loop unrolling and loop vectorizer metadata to have a common prefix.Eli Bendersky2014-06-251-1/+2
| | | | | | | | | | | | | | | | | | | [LLVM part] These patches rename the loop unrolling and loop vectorizer metadata such that they have a common 'llvm.loop.' prefix. Metadata name changes: llvm.vectorizer.* => llvm.loop.vectorizer.* llvm.loopunroll.* => llvm.loop.unroll.* This was a suggestion from an earlier review (http://reviews.llvm.org/D4090) which added the loop unrolling metadata. Patch by Mark Heffernan. llvm-svn: 211710
* Make ObjectFile and BitcodeReader always own the MemoryBuffer.Rafael Espindola2014-06-232-23/+16
| | | | | | | | | | This allows us to just use a std::unique_ptr to store the pointer to the buffer. The flip side is that they have to support releasing the buffer back to the caller. Overall this looks like a more efficient and less brittle api. llvm-svn: 211542
* Revert a C API difference that I incorrectly introduced.Rafael Espindola2014-06-182-0/+5
| | | | | | | LLVMGetBitcodeModuleInContext should not take ownership on error. I will try to localize this odd api requirement, but this should get the bots green. llvm-svn: 211213
* Remove BitcodeReader::setBufferOwned.Rafael Espindola2014-06-182-22/+10
| | | | | | | | | | We do have use cases for the bitcode reader owning the buffer or not, but we always know which one we have when we construct it. It might be possible to simplify this further, but this is a step in the right direction. llvm-svn: 211205
* Run clang-format in a small chunk of code I am about to change.Rafael Espindola2014-06-181-13/+9
| | | | llvm-svn: 211201
* Replace some assert(0)'s with llvm_unreachable.Craig Topper2014-06-181-2/+2
| | | | llvm-svn: 211141
* Convert a few loops to use ranges.Rafael Espindola2014-06-171-18/+15
| | | | llvm-svn: 211089
* IR: add "cmpxchg weak" variant to support permitted failure.Tim Northover2014-06-132-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-132-84/+82
| | | | llvm-svn: 210871
* Remove all uses of 'using std::error_code' from headers.Rafael Espindola2014-06-132-29/+30
| | | | llvm-svn: 210866
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-122-0/+2
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Remove system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Don't import error_category into the llvm namespace.Rafael Espindola2014-06-122-3/+3
| | | | llvm-svn: 210733
* Mark a few functions noexcept.Rafael Espindola2014-06-101-1/+1
| | | | | | This reduces the difference between std::error_code and llvm::error_code. llvm-svn: 210591
* Allow aliases to be unnamed_addr.Rafael Espindola2014-06-062-2/+4
| | | | | | | | | | | | | | | | | | Alias with unnamed_addr were in a strange state. It is stored in GlobalValue, the language reference talks about "unnamed_addr aliases" but the verifier was rejecting them. It seems natural to allow unnamed_addr in aliases: * It is a property of how it is accessed, not of the data itself. * It is perfectly possible to write code that depends on the address of an alias. This patch then makes unname_addr legal for aliases. One side effect is that the syntax changes for a corner case: In globals, unnamed_addr is now printed before the address space. llvm-svn: 210302
* Add a new attribute called 'jumptable' that creates jump-instruction tables ↵Tom Roeder2014-06-052-0/+4
| | | | | | | | | | | | for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
* Clauses in a landingpad are always Constant. Use a stricter type.Rafael Espindola2014-06-041-1/+1
| | | | llvm-svn: 210203
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-34/+1
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-311-26/+26
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209952
* [pr19844] Add thread local mode to aliases.Rafael Espindola2014-05-282-1/+5
| | | | | | | | | | This matches gcc's behavior. It also seems natural given that aliases contain other properties that govern how it is accessed (linkage, visibility, dll storage). Clang still has to be updated to expose this feature to C. llvm-svn: 209759
* Convert a few loops to use ranges.Rafael Espindola2014-05-261-54/+51
| | | | llvm-svn: 209628
* [modules] Add module maps for LLVM. These are not quite ready for prime-timeRichard Smith2014-05-211-0/+1
| | | | | | | yet, but only a few more Clang patches need to land. (I have 'ninja check' passing locally.) llvm-svn: 209269
OpenPOWER on IntegriCloud