summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser
Commit message (Collapse)AuthorAgeFilesLines
...
* IR: Merge UniquableMDNode back into MDNode, NFCDuncan P. N. Exon Smith2015-01-191-2/+2
| | | | | | | | | As pointed out in r226501, the distinction between `MDNode` and `UniquableMDNode` is confusing. When we need subclasses of `MDNode` that don't use all its functionality it might make sense to break it apart again, but until then this makes the code clearer. llvm-svn: 226520
* IR: Return unique_ptr from MDNode::getTemporary()Duncan P. N. Exon Smith2015-01-192-8/+6
| | | | | | | | | | | | Change `MDTuple::getTemporary()` and `MDLocation::getTemporary()` to return (effectively) `std::unique_ptr<T, MDNode::deleteTemporary>`, and clean up call sites. (For now, `DIBuilder` call sites just call `release()` immediately.) There's an accompanying change in each of clang and polly to use the new API. llvm-svn: 226504
* IR: Remove MDNodeFwdDeclDuncan P. N. Exon Smith2015-01-192-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API changes, there's no real functionality change here. `MDNode::getTemporary()` now forwards to `MDTuple::getTemporary()`, which returns a tuple with `isTemporary()` equal to true. The main point is that we can now add temporaries of other `MDNode` subclasses, needed for PR22235 (I introduced `MDNodeFwdDecl` in the first place because I didn't recognize this need, and thought they were only needed to handle forward references). A few things left out of (or highlighted by) this commit: - I've had to remove the (few) uses of `std::unique_ptr<>` to deal with temporaries, since the destructor is no longer public. `getTemporary()` should probably return the equivalent of `std::unique_ptr<T, MDNode::deleteTemporary>`. - `MDLocation::getTemporary()` doesn't exist yet (worse, it actually does exist, but does the wrong thing: `MDNode::getTemporary()` is inherited and returns an `MDTuple`). - `MDNode` now only has one subclass, `UniquableMDNode`, and the distinction between them is actually somewhat confusing. I'll fix those up next. llvm-svn: 226501
* Remove std::move that was preventing return value optimization.Richard Trieu2015-01-171-1/+1
| | | | llvm-svn: 226356
* IR: Allow 16-bits for column infoDuncan P. N. Exon Smith2015-01-161-1/+1
| | | | | | Raise the limit for column information from 8 bits to 16 bits. llvm-svn: 226291
* AsmParser/Bitcode: Add support for MDLocationDuncan P. N. Exon Smith2015-01-132-2/+150
| | | | | | | | | | | | This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
* AsmParser: Use subclass API instead of MDNode wrappers, NFCDuncan P. N. Exon Smith2015-01-121-4/+4
| | | | | | | | Use subclass API instead of the wrappers in `MDNode` in the assembly parser. This will make the code easier to follow once we have multiple subclasses. llvm-svn: 225711
* AsmParser: Factor duplicated code into ParseMDNode(), NFCDuncan P. N. Exon Smith2015-01-122-27/+24
| | | | llvm-svn: 225710
* AsmParser: Reorder ParseMetadata() logic, NFCDuncan P. N. Exon Smith2015-01-121-13/+13
| | | | llvm-svn: 225709
* AsmParser: Simplify ParseMDTuple(), NFCDuncan P. N. Exon Smith2015-01-121-4/+1
| | | | llvm-svn: 225708
* AsmParser: ParseMDNode() => ParseMDTuple(), NFCDuncan P. N. Exon Smith2015-01-122-5/+5
| | | | | | This isn't parsing arbitrary subclasses of `MDNode`, just `MDTuple`. llvm-svn: 225702
* AsmParser: Remove unused version of ParseMDNodeID()Duncan P. N. Exon Smith2015-01-122-18/+6
| | | | | | | Merge the two versions of `ParseMDNodeID()` now that no one needs special forward references. llvm-svn: 225699
* AsmParser: Use normal references for metadata attachments, NFCDuncan P. N. Exon Smith2015-01-122-39/+6
| | | | | | | | Remove special parsing logic for metadata attachments. Now that `DebugLoc` is stored normally (since the metadata/value split), we don't need this special forward referencing logic. llvm-svn: 225698
* IR: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Split `GenericMDNode` into two classes (with more descriptive names). - `UniquableMDNode` will be a common subclass for `MDNode`s that are sometimes uniqued like constants, and sometimes 'distinct'. This class gets the (short-lived) RAUW support and related API. - `MDTuple` is the basic tuple that has always been returned by `MDNode::get()`. This is as opposed to more specific nodes to be added soon, which have additional fields, custom assembly syntax, and extra semantics. This class gets the hash-related logic, since other sublcasses of `UniquableMDNode` may need to hash based on other fields. To keep this diff from getting too big, I've added casts to `MDTuple` that won't really scale as new subclasses of `UniquableMDNode` are added, but I'll clean those up incrementally. (No functionality change intended.) llvm-svn: 225682
* IR: Add 'distinct' MDNodes to bitcode and assemblyDuncan P. N. Exon Smith2015-01-084-4/+14
| | | | | | | | | | | | | | | | | | Propagate whether `MDNode`s are 'distinct' through the other types of IR (assembly and bitcode). This adds the `distinct` keyword to assembly. Currently, no one actually calls `MDNode::getDistinct()`, so these nodes only get created for: - self-references, which are never uniqued, and - nodes whose operands are replaced that hit a uniquing collision. The concept of distinct nodes is still not quite first-class, since distinct-ness doesn't yet survive across `MapMetadata()`. Part of PR22111. llvm-svn: 225474
* Change the .ll syntax for comdats and add a syntactic sugar.Rafael Espindola2015-01-062-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make comdats always explicit in the IR, we decided to make the syntax a bit more compact for the case of a GlobalObject in a comdat with the same name. Just dropping the $name causes problems for @foo = globabl i32 0, comdat $bar = comdat ... and declare void @foo() comdat $bar = comdat ... So the syntax is changed to @g1 = globabl i32 0, comdat($c1) @g2 = globabl i32 0, comdat and declare void @foo() comdat($c1) declare void @foo() comdat llvm-svn: 225302
* IR: Make metadata typeless in assemblyDuncan P. N. Exon Smith2014-12-152-74/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud