summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser/LLParser.h
Commit message (Collapse)AuthorAgeFilesLines
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-311-0/+1
| | | | | | | | | | This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
* Refactor duplicated code. NFC.Rafael Espindola2016-05-121-6/+4
| | | | | | Linkage is always followed by visibility and dll storage. llvm-svn: 269286
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* Add the allocsize attribute to LLVM.George Burgess IV2016-04-121-1/+5
| | | | | | | | | | | | | | | | `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
* [IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similarDmitry Polukhin2016-04-051-3/+5
| | | | | | | | | | | Second part extracted from http://reviews.llvm.org/D15525 Use GlobalIndirectSymbol in all cases when aliases and ifuncs have something in common. Differential Revision: http://reviews.llvm.org/D18754 llvm-svn: 265382
* Restore "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-301-0/+1
| | | | | | | This restores commit 264869, with a fix for windows bots to properly escape '\' in the path when serializing out. Added test. llvm-svn: 264884
* Revert "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson2016-03-301-1/+0
| | | | | | | | | This reverts commit r264869. I am seeing Windows bot failures due to the "\" in the path being mishandled at some point (seems to be interpreted wrongly at some point and llvm-as | llvm-dis is yielding some junk characters). Need to investigate. llvm-svn: 264871
* [ThinLTO] Serialize the Module SourceFileName to/from LLVM assemblyTeresa Johnson2016-03-301-0/+1
| | | | | | | | | | | | | | | | | | | Summary: This change serializes out and in the SourceFileName to LLVM assembly so that it is preserved through "llvm-dis | llvm-as". This is necessary to ensure that the global identifiers created for local values in the module summary index are the same even if the bitcode is streamed out and read back from LLVM assembly. Serializing the summary itself to LLVM assembly is in progress. Reviewers: joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D18588 llvm-svn: 264869
* [AsmParser] Expose an API to parse a string starting with a type.Quentin Colombet2016-03-081-1/+2
| | | | | | | | | | | | Without actually parsing a type it is difficult to perdict where the type definition ends. In other words, instead of expecting the user of the parser API to hand over only the relevant bits of the string being parsed, take the whole string, parse the type, and get back the number of characters that have been read. This will be used by the MIR testing infrastructure. llvm-svn: 262884
* [AsmParser] Add a function to parse a standalone type.Quentin Colombet2016-03-071-0/+2
| | | | | | | This is useful for MIR serialization. Indeed generic machine instructions must have a type and we don't want to duplicate the logic in the MIParser. llvm-svn: 262868
* [IR] Remove terminatepadDavid Majnemer2015-12-141-1/+0
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-121-21/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-9/+9
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* [Bitcode][Asm] Teach LLVM to read and write operand bundles.Sanjoy Das2015-09-241-0/+4
| | | | | | | | | | | | | | | | | | Summary: This also adds the first set of tests for operand bundles. The optimizer has not been audited to ensure that it does the right thing with operand bundles. Depends on D12456. Reviewers: reames, chandlerc, majnemer, dexonsmith, kmod, JosephTremoulet, rnk, bogner Subscribers: maksfb, llvm-commits Differential Revision: http://reviews.llvm.org/D12457 llvm-svn: 248551
* Fix assertion failure in LLParser::ConvertValIDToValueKarl Schimpf2015-09-031-1/+1
| | | | | | | | | | | Summary: Fixes bug 24645. Problem appears to be that the type may be undefined when ConvertValIDToValue is called. Reviewers: kcc Subscribers: llvm-commits llvm-svn: 246779
* [WinEH] Add cleanupendpad instructionJoseph Tremoulet2015-09-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 llvm-svn: 246751
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
* AsmParser: Save and restore the parsing state for types using SlotMapping.Alex Lorenz2015-08-211-1/+5
| | | | | | | | | | | | | | | | | | | | | This commit extends the 'SlotMapping' structure and includes mappings for named and numbered types in it. The LLParser is extended accordingly to fill out those mappings at the end of module parsing. This information is useful when we want to parse standalone constant values at a later stage using the 'parseConstantValue' method. The constant values can be constant expressions, which can contain references to types. In order to parse such constant values, we have to restore the internal named and numbered mappings for the types in LLParser, otherwise the parser will report a parsing error. Therefore, this commit also introduces a new method called 'restoreParsingState' to LLParser, which uses the slot mappings to restore some of its internal parsing state. This commit is required to serialize constant value pointers in the machine memory operands for the MIR format. Reviewers: Duncan P. N. Exon Smith llvm-svn: 245740
* Try to fix the build for C++ standard libraries missing std::map::emplaceDavid Blaikie2015-08-031-5/+5
| | | | llvm-svn: 243899
* Recommit r243824: -Wdeprecated-clean: Fix cases of violating the rule of 5 ↵David Blaikie2015-08-031-9/+11
| | | | | | | | | | | | in ways that are deprecated in C++11 This reverts commit r243888, recommitting r243824. This broke the Windows build due to a difference in the C++ standard library implementation. Using emplace/forward_as_tuple should ensure there's no need to copy ValIDs. llvm-svn: 243896
* Revert "-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways ↵Reid Kleckner2015-08-031-11/+9
| | | | | | | | | | that are deprecated in C++11" This reverts commit r243824. It broke the build on Windows. llvm-svn: 243888
* Currently string attributes on function arguments/return values can be ↵Artur Pilipenko2015-08-031-0/+2
| | | | | | | | | | | | | | | generated using LLVM API. However they are not supported in parser. So, the following scenario will fail: * generate function with string attribute using API, * dump it in LL format, * try to parse. Add parser support for string attributes to fix the issue. Reviewed By: reames, hfinkel Differential Revision: http://reviews.llvm.org/D11058 llvm-svn: 243877
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-011-9/+11
| | | | | | deprecated in C++11 llvm-svn: 243824
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+9
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* [opaque pointers] Avoid the use of pointee types when parsing inline asm in IRDavid Blaikie2015-07-271-1/+2
| | | | | | | | | | | | | | When parsing calls to inline asm the pointee type (of the pointer type representing the value type of the InlineAsm value) was used. To avoid using it, use the ValID structure to ferry the FunctionType directly through to the InlineAsm construction. This is a bit of a workaround - alternatively the inline asm could explicitly describe the type but that'd be verbose/redundant in the IR and so long as the inline asm calls directly in the context of a call or invoke, this should suffice. llvm-svn: 243349
* AsmParser: Add a function to parse a standalone constant value.Alex Lorenz2015-07-171-0/+3
| | | | | | | | | | | | | | This commit extends the interface provided by the AsmParser library by adding a function that allows the user to parse a standalone contant value. This change is useful for MIR serialization, as it will allow the MIR Parser to parse the constant values in a machine constant pool. Reviewers: Duncan P. N. Exon Smith Differential Revision: http://reviews.llvm.org/D10280 llvm-svn: 242579
* Revert the new EH instructionsDavid Majnemer2015-07-101-9/+0
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-0/+9
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* AsmParser: Extend the API to make the global value and metadata node slot ↵Alex Lorenz2015-06-231-3/+6
| | | | | | | | | | | | | | | | | | mappings publicly accessible. This commit creates a new structure called 'SlotMapping' in the AsmParser library. This structure can be passed into the public parsing APIs from the AsmParser library in order to extract the data structures that map from slot numbers to unnamed global values and metadata nodes. This change is useful for MIR Serialization, as the MIR Parser has to lookup the unnamed global values and metadata nodes by their slot numbers. Reviewers: Duncan P. N. Exon Smith Differential Revision: http://reviews.llvm.org/D10551 llvm-svn: 240427
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* IR: Add assembly/bitcode support for function metadata attachmentsDuncan P. N. Exon Smith2015-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
* LLParser: Simplify ParseInstructionMetadata(), NFCDuncan P. N. Exon Smith2015-04-241-1/+1
| | | | | | | | Remove unused `PFS` variable and take the `Instruction` by reference. (Not really related to PR23340, but might as well clean this up while I'm here.) llvm-svn: 235782
* LLParser: Split out ParseMetadataAttachment(), NFCDuncan P. N. Exon Smith2015-04-241-0/+1
| | | | | | Make the code reusable for `Function` metadata attachments (PR23340). llvm-svn: 235778
* [IR] Introduce a dereferenceable_or_null(N) attribute.Sanjoy Das2015-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
* Revert "unique_ptrify ValID::ConstantStructElts"Reid Kleckner2015-03-041-9/+5
| | | | | | | | | | | | | | | | | | | | | This reverts r231200 and r231204. The second one added an explicit move ctor for MSVC. This change broke the clang-cl self-host due to weirdness in MSVC's implementation of std::map::insert. Somehow we lost our rvalue ref-ness when going through variadic placement new: template <class _Objty, class... _Types> void construct(_Objty *_Ptr, _Types &&... _Args) { // construct _Objty(_Types...) at _Ptr ::new ((void *)_Ptr) _Objty(_STD forward<_Types>(_Args)...); } For some reason, Clang decided to call the deleted std::pair copy constructor at this point. Needs further investigation, once I can build. llvm-svn: 231269
* Workaround MSVC not providing implicit move membersDavid Blaikie2015-03-041-0/+8
| | | | llvm-svn: 231204
* unique_ptrify ValID::ConstantStructEltsDavid Blaikie2015-03-041-5/+1
| | | | llvm-svn: 231200
* Revert "Remove the explicit SDNodeIterator::operator= in favor of the ↵David Blaikie2015-03-031-1/+5
| | | | | | | | | | | implicit default" Accidentally committed a few more of these cleanup changes than intended. Still breaking these out & tidying them up. This reverts commit r231135. llvm-svn: 231136
* Remove the explicit SDNodeIterator::operator= in favor of the implicit defaultDavid Blaikie2015-03-031-5/+1
| | | | | | | | | | There doesn't seem to be any need to assert that iterator assignment is between iterators over the same node - if you want to reuse an iterator variable to iterate another node, that's perfectly acceptable. Just don't mix comparisons between iterators into disjoint sequences, as usual. llvm-svn: 231135
* AsmWriter/Bitcode: MDSubprogramDuncan P. N. Exon Smith2015-02-131-1/+2
| | | | llvm-svn: 229014
* AsmParser: Switch some vectors to mapsDavid Majnemer2015-02-111-2/+2
| | | | | | This speeds up parsing .ll files with metadata nodes with large IDs. llvm-svn: 228812
* AsmParser: Add stubs for specialized MDNodes, NFCDuncan P. N. Exon Smith2015-02-101-2/+4
| | | | | | Well, the exact error from the failed parse will change, but... llvm-svn: 228644
* AsmParser: Move MDField details to source file, NFCDuncan P. N. Exon Smith2015-02-041-38/+2
| | | | | | | | Move all the types of `MDField` to an anonymous namespace in the source file. This also eliminates the duplication of `ParseMDField()` declarations in the header for each new field type. llvm-svn: 228211
* AsmParser: Simplify MDUnsignedFieldDuncan P. N. Exon Smith2015-02-041-9/+6
| | | | | | We only need `uint64_t` for storage. llvm-svn: 228205
* AsmParser: Recognize DW_TAG_* constantsDuncan P. N. Exon Smith2015-02-031-0/+4
| | | | | | | Recognize `DW_TAG_` constants in assembly, and output it by default for `GenericDebugNode`. llvm-svn: 228042
* IR: Assembly and bitcode for GenericDebugNodeDuncan P. N. Exon Smith2015-02-031-2/+12
| | | | llvm-svn: 228041
* AsmParser: PARSE_MD_FIELD() => ParseMDField(), NFCDuncan P. N. Exon Smith2015-01-201-0/+1
| | | | | | Extract most of `PARSE_MD_FIELD()` into a function. llvm-svn: 226539
* AsmParser: Split up ParseMDFieldsImpl(), NFCDuncan P. N. Exon Smith2015-01-191-0/+2
| | | | llvm-svn: 226526
OpenPOWER on IntegriCloud