summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser
Commit message (Collapse)AuthorAgeFilesLines
* AsmParser: Don't crash on an ill-formed MDNodeVectorDavid Majnemer2014-12-111-2/+2
| | | | llvm-svn: 224056
* AsmParser: Don't crash on an ill-formed MDNodeVectorDavid Majnemer2014-12-111-2/+2
| | | | llvm-svn: 224053
* AsmParser: Don't allow null bytes in BB labelsDavid Majnemer2014-12-101-1/+6
| | | | | | | Since Value objects can't have null bytes in their name, we shouldn't allow them in the labels of basic blocks. llvm-svn: 223907
* AsmParser: Don't crash if a null byte is inside a quoted stringDavid Majnemer2014-12-102-52/+34
| | | | | | | We don't allow Value* to have names which contain null bytes. The AsmParser should reject .ll files that try to do this. llvm-svn: 223869
* AsmParser: Verifier that the contents of a hex integer are hexDavid Majnemer2014-12-091-1/+7
| | | | llvm-svn: 223856
* AsmParser: Don't crash on short hex constants for fp128 typesDavid Majnemer2014-12-091-5/+7
| | | | | | | If we see 0xL01, treat it like 0xL00000000000000000000000000000001 instead of crashing. llvm-svn: 223811
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-092-62/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* AsmParser: Don't crash on malformed attribute groupsDavid Majnemer2014-12-091-1/+3
| | | | | | This fixes PR21785. llvm-svn: 223801
* Reland r223754David Majnemer2014-12-091-6/+9
| | | | | | | The commit is identical except a reference to `GV' should have been to `GVal'. llvm-svn: 223756
* Revert "AsmParser: Reject invalid mismatch between forward ref and def"David Majnemer2014-12-091-8/+5
| | | | | | This reverts commit r223754. I've upset the buildbots. llvm-svn: 223755
* AsmParser: Reject invalid mismatch between forward ref and defDavid Majnemer2014-12-091-5/+8
| | | | | | | | | Don't assume that the forward referenced entity was of the same global-kind as the new entity. This fixes PR21779. llvm-svn: 223754
* IR: Add missing tests for function-local metadataDuncan P. N. Exon Smith2014-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* IR: Disallow function-local metadata attachmentsDuncan P. N. Exon Smith2014-12-061-0/+4
| | | | | | | | Metadata attachments to instructions cannot be function-local. This is part of PR21532. llvm-svn: 223574
* IR: Disallow complicated function-local metadataDuncan P. N. Exon Smith2014-12-061-0/+13
| | | | | | | | | | Disallow complex types of function-local metadata. The only valid function-local metadata is an `MDNode` whose sole argument is a non-metadata function-local value. Part of PR21532. llvm-svn: 223564
* Prologue supportPeter Collingbourne2014-12-033-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
* Parse 'ghccc' in .ll files as the GHC convention (cc 10)Reid Kleckner2014-12-013-1/+5
| | | | | | | Previously we just used "cc 10" in the .ll files, but that isn't very human readable. llvm-svn: 223076
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-1/+1
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* X86: Implement the vectorcall calling conventionReid Kleckner2014-10-283-1/+4
| | | | | | | | | | | | | | | | | | | | This is a Microsoft calling convention that supports both x86 and x86_64 subtargets. It passes vector and floating point arguments in XMM0-XMM5, and passes them indirectly once they are consumed. Homogenous vector aggregates of up to four elements can be passed in sequential vector registers, but this part is not implemented in LLVM and will be handled in Clang. On 32-bit x86, it is similar to fastcall in that it uses ecx:edx as integer register parameters and is callee cleanup. On x86_64, it delegates to the normal win64 calling convention. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D5943 llvm-svn: 220745
* Make CallingConv::ID an alias of "unsigned".Alexey Samsonov2014-09-102-10/+6
| | | | | | | | | | | | | | | | | | | | Summary: Make CallingConv::ID a plain unsigned instead of enum with a fixed set of valus. LLVM IR allows arbitraty calling conventions (you are free to write cc12345), and loading them as enum is an undefined behavior. This was reported by UBSan. Test Plan: llvm regression test suite Reviewers: nicholas Reviewed By: nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5248 llvm-svn: 217529
* Fix typos in comments, NFCRobin Morisset2014-08-291-1/+1
| | | | | | | | | | | | | | Summary: Just fixing comments, no functional change. Test Plan: N/A Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5130 llvm-svn: 216784
* Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola2014-08-261-13/+10
| | | | | | | | | | | | | The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
* Declare that musttail calls in variadic functions forward the ellipsisReid Kleckner2014-08-262-3/+22
| | | | | | | | | | | | | | | | | Summary: There is no functionality change here except in the way we assemble and dump musttail calls in variadic functions. There's really no need to separate out the bits for musttail and "is forwarding varargs" on call instructions. A musttail call by definition has to forward the ellipsis or it would fail verification. Reviewers: chandlerc, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4892 llvm-svn: 216423
* Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using ↵David Blaikie2014-08-211-1/+1
| | | | | | std::unique_ptr llvm-svn: 216223
* Split parseAssembly into parseAssembly and parseAssemblyInto.Rafael Espindola2014-08-191-6/+13
| | | | | | | This should restore the functionality of parsing new code into an existing module without the confusing interface. llvm-svn: 216031
* IR: Implement uselistorder assembly directivesDuncan P. N. Exon Smith2014-08-194-4/+156
| | | | | | | | | | Implement `uselistorder` and `uselistorder_bb` assembly directives, which allow the use-list order to be recovered when round-tripping to assembly. This is the bulk of PR20515. llvm-svn: 216025
* Modernize the .ll parsing interface.Rafael Espindola2014-08-191-18/+17
| | | | | | | | | | * Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
* LLParser: Handle BlockAddresses on-the-flyDuncan P. N. Exon Smith2014-08-192-93/+126
| | | | | | | | | | | | | | | | | | | | | | | | Previously all `blockaddress()` constants were treated as forward references. They were resolved twice: once at the end of the function in question, and again at the end of the module. Furthermore, if the same blockaddress was referenced N times, the parser created N distinct `GlobalVariable`s (one for each reference). Instead, resolve all block addresses at the beginning of the function, creating the standard `BasicBlock` forward references used for all other basic block references. After the function, all references can be resolved immediately. To check for the condition of parsing block addresses from within the same function, I created a reference to the current per-function-state in `BlockAddressPFS`. Also, create only one forward-reference per basic block. Because forward references to block addresses are rare, the data structure here shouldn't matter. If somehow it does someday, this can be pretty easily changed to a `DenseMap<std::pair<ValID, ValID>, GV>`. This is part of PR20515. llvm-svn: 215952
* These classes only need a StringRef, not a MemoryBuffer.Rafael Espindola2014-08-184-8/+8
| | | | llvm-svn: 215945
* Delete unused method.Rafael Espindola2014-08-182-6/+0
| | | | llvm-svn: 215944
* Pass a std::uinque_ptr to ParseAssembly to make the ownership explicit. NFC.Rafael Espindola2014-08-171-10/+9
| | | | llvm-svn: 215852
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-133-6/+6
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Remove dead code in conditionDuncan P. N. Exon Smith2014-08-051-2/+2
| | | | | | | Whether or not it's appropriate, labels have been first-class types since r51511. llvm-svn: 214908
* Use "weak alias" instead of "alias weak"Rafael Espindola2014-07-302-16/+13
| | | | | | | | | | | | | | | | | | | | | 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
* AsmParser: remove deprecated LLIR supportSaleem Abdulrasool2014-07-233-19/+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
* Add a dereferenceable attributeHal Finkel2014-07-184-0/+53
| | | | | | | | | 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
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-061-4/+5
| | | | llvm-svn: 212405
* IR: Add COMDATs to the IRDavid Majnemer2014-06-275-8/+165
| | | | | | | | | | | | | | | | 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
* ParseIR: don't take ownership of the MemoryBufferAlp Toker2014-06-271-2/+1
| | | | | | | | | | clang was needlessly duplicating whole memory buffer contents in an attempt to satisfy unclear ownership semantics. Let's just hide internal LLVM quirks and present a simple non-owning interface. The public C API preserves previous behaviour for stability. llvm-svn: 211861
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-3/+4
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-4/+3
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* Rename loop unrolling and loop vectorizer metadata to have a common prefix.Eli Bendersky2014-06-251-0/+1
| | | | | | | | | | | | | | | | | | | [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
* IR: add "cmpxchg weak" variant to support permitted failure.Tim Northover2014-06-133-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-2/+1
| | | | llvm-svn: 210871
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-0/+1
| | | | | | 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
* Allow aliases to be unnamed_addr.Rafael Espindola2014-06-062-20/+32
| | | | | | | | | | | | | | | | | | 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-053-0/+5
| | | | | | | | | | | | 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-2/+3
| | | | llvm-svn: 210203
* Update comments to match reality.Rafael Espindola2014-06-031-4/+4
| | | | llvm-svn: 210125
* Fix a small bug in the parsing of anonymous globals.Rafael Espindola2014-06-031-0/+2
| | | | | | | | | | | | It was able to parse hidden dllexport global i32 42 but not dllexport global i32 42 llvm-svn: 210121
OpenPOWER on IntegriCloud