summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Add 'nonnull', a new parameter and return attribute which indicates that the ↵Nick Lewycky2014-05-202-0/+4
| | | | | | pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
* Use create methods since msvc doesn't handle delegating constructors.Rafael Espindola2014-05-171-2/+2
| | | | llvm-svn: 209076
* Reduce abuse of default values in the GlobalAlias constructor.Rafael Espindola2014-05-171-2/+2
| | | | | | This is in preparation for adding an optional offset. llvm-svn: 209073
* Add comdat key field to llvm.global_ctors and llvm.global_dtorsReid Kleckner2014-05-161-2/+5
| | | | | | | | | | | | | | This allows us to put dynamic initializers for weak data into the same comdat group as the data being initialized. This is necessary for MSVC ABI compatibility. Once we have comdats for guard variables, we can use the combination to help GlobalOpt fire more often for weak data with guarded initialization on other platforms. Reviewers: nlewycky Differential Revision: http://reviews.llvm.org/D3499 llvm-svn: 209015
* Fix most of PR10367.Rafael Espindola2014-05-161-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of GlobalAlias so that it doesn't take a ConstantExpr anymore. It now points directly to a GlobalObject, but its type is independent of the aliasee type. To avoid changing all alias related tests in this patches, I kept the common syntax @foo = alias i32* @bar to mean the same as now. The cases that used to use cast now use the more general syntax @foo = alias i16, i32* @bar. Note that GlobalAlias now behaves a bit more like GlobalVariable. We know that its type is always a pointer, so we omit the '*'. For the bitcode, a nice surprise is that we were writing both identical types already, so the format change is minimal. Auto upgrade is handled by looking through the casts and no new fields are needed for now. New bitcode will simply have different types for Alias and Aliasee. One last interesting point in the patch is that replaceAllUsesWith becomes smart enough to avoid putting a ConstantExpr in the aliasee. This seems better than checking and updating every caller. A followup patch will delete getAliasedGlobal now that it is redundant. Another patch will add support for an explicit offset. llvm-svn: 209007
* Small dyn_cast and auto cleanup.Rafael Espindola2014-05-161-3/+3
| | | | llvm-svn: 208993
* Change the GlobalAlias constructor to look a bit more like GlobalVariable.Rafael Espindola2014-05-161-2/+4
| | | | | | | This is part of the fix for pr10367. A GlobalAlias always has a pointer type, so just have the constructor build the type. llvm-svn: 208983
* IR: Don't allow non-default visibility on local linkageDuncan P. N. Exon Smith2014-05-071-3/+10
| | | | | | | | | | | | | | | | | Visibilities of `hidden` and `protected` are meaningless for symbols with local linkage. - Change the assembler to reject non-default visibility on symbols with local linkage. - Change the bitcode reader to auto-upgrade `hidden` and `protected` to `default` when the linkage is local. - Update LangRef. <rdar://problem/16141113> llvm-svn: 208263
* [IR] Make {extract,insert}element accept an index of any integer type.Michael J. Spencer2014-05-012-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following C code llvm currently generates suboptimal code for x86-64: __m128 bss4( const __m128 *ptr, size_t i, size_t j ) { float f = ptr[i][j]; return (__m128) { f, f, f, f }; } ================================================= define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 { %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i %a2 = load <4 x float>* %a1, align 16, !tbaa !1 %a3 = trunc i64 %j to i32 %a4 = extractelement <4 x float> %a2, i32 %a3 %a5 = insertelement <4 x float> undef, float %a4, i32 0 %a6 = insertelement <4 x float> %a5, float %a4, i32 1 %a7 = insertelement <4 x float> %a6, float %a4, i32 2 %a8 = insertelement <4 x float> %a7, float %a4, i32 3 ret <4 x float> %a8 } ================================================= shlq $4, %rsi addq %rdi, %rsi movslq %edx, %rax vbroadcastss (%rsi,%rax,4), %xmm0 retq ================================================= The movslq is uneeded, but is present because of the trunc to i32 and then sext back to i64 that the backend adds for vbroadcastss. We can't remove it because it changes the meaning. The IR that clang generates is already suboptimal. What clang really should emit is: %a4 = extractelement <4 x float> %a2, i64 %j This patch makes that legal. A separate patch will teach clang to do it. Differential Revision: http://reviews.llvm.org/D3519 llvm-svn: 207801
* raw_ostream: Forward declare OpenFlags and include FileSystem.h only where ↵Benjamin Kramer2014-04-291-0/+1
| | | | | | necessary. llvm-svn: 207593
* [C++] Use 'nullptr'.Craig Topper2014-04-281-10/+10
| | | | llvm-svn: 207394
* Add 'musttail' marker to call instructionsReid Kleckner2014-04-242-3/+9
| | | | | | | | | | | | This is similar to the 'tail' marker, except that it guarantees that tail call optimization will occur. It also comes with convervative IR verification rules that ensure that tail call optimization is possible. Reviewers: nicholas Differential Revision: http://llvm-reviews.chandlerc.com/D3240 llvm-svn: 207143
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-154-62/+62
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* All new elements except the last one initialized to NULL. Ideally, once ↵Karthik Bhat2014-03-271-7/+7
| | | | | | | | | parsing is complete, all elements should be non-NULL. To safe-guard BitcodeReader, this patch adds null check for all access to these list. Patch by Dinesh Dwivedi! llvm-svn: 204920
OpenPOWER on IntegriCloud