summaryrefslogtreecommitdiffstats
path: root/llvm/lib/AsmParser/LLParser.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Support align attribute for return valuesArtur Pilipenko2015-09-181-1/+7
| | | | | | | | Reviewed By: reames Differential Revision: http://reviews.llvm.org/D12844 llvm-svn: 247984
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-2/+3
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* [opaque pointer type] Add textual IR support for explicit type parameter for ↵David Blaikie2015-09-111-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | global aliases update.py: import fileinput import sys import re alias_match_prefix = r"(.*(?:=|:|^)\s*(?:external |)(?:(?:private|internal|linkonce|linkonce_odr|weak|weak_odr|common|appending|extern_weak|available_externally) )?(?:default |hidden |protected )?(?:dllimport |dllexport )?(?:unnamed_addr |)(?:thread_local(?:\([a-z]*\))? )?alias" plain = re.compile(alias_match_prefix + r" (.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|addrspacecast|\[\[[a-zA-Z]|\{\{).*$)") cast = re.compile(alias_match_prefix + r") ((?:bitcast|inttoptr|addrspacecast)\s*\(.* to (.*?)(| addrspace\(\d+\) *)\*\)\s*(?:;.*)?$)") gep = re.compile(alias_match_prefix + r") ((?:getelementptr)\s*(?:inbounds)?\s*\((?P<type>.*), (?P=type)(?:\s*addrspace\(\d+\)\s*)?\* .*\)\s*(?:;.*)?$)") def conv(line): m = re.match(cast, line) if m: return m.group(1) + " " + m.group(3) + ", " + m.group(2) m = re.match(gep, line) if m: return m.group(1) + " " + m.group(3) + ", " + m.group(2) m = re.match(plain, line) if m: return m.group(1) + ", " + m.group(2) + m.group(3) + "*" + m.group(4) + "\n" return line for line in sys.stdin: sys.stdout.write(conv(line)) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh llvm-svn: 247378
* Fix PR 24633 - Handle undef values when parsing standalone constants.Alex Lorenz2015-09-091-0/+1
| | | | llvm-svn: 247145
* Allow global address space forward decls using IDs in .ll files.Karl Schimpf2015-09-031-16/+13
| | | | | | | | | | Summary: This fixes bugzilla bug 24656. Fixes the case where there is a forward reference to a global variable using an ID (i.e. @0). It does this by passing the address space of the initializer pointer for which the forward referenced global is used. llvm-svn: 246788
* Fix assertion failure in LLParser::ConvertValIDToValueKarl Schimpf2015-09-031-2/+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/+30
| | | | | | | | | | | | | | | | | | | | | | | 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
* DI: Require subprogram definitions to be distinctDuncan P. N. Exon Smith2015-08-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | As a follow-up to r246098, require `DISubprogram` definitions (`isDefinition: true`) to be 'distinct'. Specifically, add an assembler check, a verifier check, and bitcode upgrading logic to combat testcase bitrot after the `DIBuilder` change. While working on the testcases, I realized that test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its purpose was to check for a corner case in PR22792 where two subprogram definitions match exactly and share the same metadata node. The new verifier check, requiring that subprogram definitions are 'distinct', precludes that possibility. I updated almost all the IR with the following script: git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' | grep -v test/Bitcode | xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/' Likely some variant of would work for out-of-tree testcases. llvm-svn: 246327
* [WinEH] Require token linkage in EH pad/ret signaturesJoseph Tremoulet2015-08-231-48/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+20
| | | | | | | | | | | | | | | | | | | | | 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
* [IR] Give catchret an optional 'return value' operandDavid Majnemer2015-08-151-3/+14
| | | | | | | | | | | Some personality routines require funclet exit points to be clearly marked, this is done by producing a token at the funclet pad and consuming it at the corresponding ret instruction. CleanupReturnInst already had a spot for this operand but CatchReturnInst did not. Other personality routines don't need to use this which is why it has been made optional. llvm-svn: 245149
* Fix with a bit more care. (but only a bit)David Blaikie2015-08-031-2/+3
| | | | llvm-svn: 243903
* Try to fix the build for C++ standard libraries missing std::map::emplaceDavid Blaikie2015-08-031-3/+2
| | | | llvm-svn: 243899
* Recommit r243824: -Wdeprecated-clean: Fix cases of violating the rule of 5 ↵David Blaikie2015-08-031-9/+12
| | | | | | | | | | | | 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-9/+6
| | | | | | | | | | that are deprecated in C++11" This reverts commit r243824. It broke the build on Windows. llvm-svn: 243888
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-6/+7
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* Currently string attributes on function arguments/return values can be ↵Artur Pilipenko2015-08-031-7/+24
| | | | | | | | | | | | | | | 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
* De-constify pointers to Type since they can't be modified. NFCCraig Topper2015-08-011-2/+2
| | | | | | This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-011-6/+9
| | | | | | deprecated in C++11 llvm-svn: 243824
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-311-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags, using `DW_TAG_variable` in their place Stop exposing the `tag:` field at all in the assembly format for `DILocalVariable`. Most of the testcase updates were generated by the following sed script: find test/ -name "*.ll" -o -name "*.mir" | xargs grep -l 'DILocalVariable' | xargs sed -i '' \ -e 's/tag: DW_TAG_arg_variable, //' \ -e 's/tag: DW_TAG_auto_variable, //' There were only a handful of tests in `test/Assembly` that I needed to update by hand. (Note: a follow-up could change `DILocalVariable::DILocalVariable()` to set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable` (as appropriate), instead of having that logic magically in the backend in `DbgVariable`. I've added a FIXME to that effect.) llvm-svn: 243774
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-311-0/+161
| | | | | | | | | | 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-6/+9
| | | | | | | | | | | | | | 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/+35
| | | | | | | | | | | | | | 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
* Add argmemonly attribute.Igor Laevsky2015-07-111-29/+38
| | | | | | | | This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
* Add support for fast-math flags to the FCmp instruction.James Molloy2015-07-101-2/+11
| | | | | | | | | | | | | | FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
* Revert the new EH instructionsDavid Majnemer2015-07-101-161/+0
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* Address Joseph's review comments.David Majnemer2015-07-101-2/+2
| | | | llvm-svn: 241890
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-0/+161
| | | | | | | | | | | | | | | 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
* Extended syntax of vector version of getelementptr instruction.Elena Demikhovsky2015-07-091-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | The justification of this change is here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/082989.html According to the current GEP syntax, vector GEP requires that each index must be a vector with the same number of elements. %A = getelementptr i8, <4 x i8*> %ptrs, <4 x i64> %offsets In this implementation I let each index be or vector or scalar. All vector indices must have the same number of elements. The scalar value will mean the splat vector value. (1) %A = getelementptr i8, i8* %ptr, <4 x i64> %offsets or (2) %A = getelementptr i8, <4 x i8*> %ptrs, i64 %offset In all cases the %A type is <4 x i8*> In the case (2) we add the same offset to all pointers. The case (1) covers C[B[i]] case, when we have the same base C and different offsets B[i]. The documentation is updated. http://reviews.llvm.org/D10496 llvm-svn: 241788
* Add a DIModule metadata node to the IR.Adrian Prantl2015-06-291-0/+18
| | | | | | | | | | | | | | | | | | | It is meant to be used to record modules @imported by the current compile unit, so a debugger an import the same modules to replicate this environment before dropping into the expression evaluator. DIModule is a sibling to DINamespace and behaves quite similarly. In addition to the name of the module it also records the module configuration details that are necessary to uniquely identify the module. This includes the configuration macros (e.g., -DNDEBUG), the include path where the module.map file is to be found, and the isysroot. The idea is that the backend will turn this into a DW_TAG_module. http://reviews.llvm.org/D9614 rdar://problem/20965932 llvm-svn: 241017
* AsmParser: Extend the API to make the global value and metadata node slot ↵Alex Lorenz2015-06-231-0/+9
| | | | | | | | | | | | | | | | | | 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
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-7/+8
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Allow aliases to be unnamed.Rafael Espindola2015-06-171-0/+3
| | | | | | | | | | If globals can be unnamed, there is no reason for aliases to be different. The restriction was there since the original implementation in r36435. I can only guess it was there because of the old bison parser for the old alias syntax. llvm-svn: 239921
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* DebugInfo: Really support 2^16 arguments in a subprogramDuncan P. N. Exon Smith2015-06-021-1/+1
| | | | | | | | As a follow-up to r235955, actually support up to 65535 arguments in a subprogram. r235955 missed assembly support, having only tested the new limit via C++ unit tests. Code patch by Amjad Aboud. llvm-svn: 238854
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-7/+7
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* Fix typos in variable/grammar names.Eric Christopher2015-05-281-6/+6
| | | | llvm-svn: 238523
* Add initial support for the convergent attribute.Owen Anderson2015-05-261-0/+1
| | | | llvm-svn: 238264
* Simplify boolean conditional return statements.Rafael Espindola2015-05-261-4/+1
| | | | | | Patch by Richard <legalize@xmission.com>. llvm-svn: 238250
* IR / debug info: Add a DWOId field to DICompileUnit,Adrian Prantl2015-05-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | so DWARF skeleton CUs can be expression in IR. A skeleton CU is a (typically empty) DW_TAG_compile_unit that has a DW_AT_(GNU)_dwo_name and a DW_AT_(GNU)_dwo_id attribute. It is used to refer to external debug info. This is a prerequisite for clang module debugging as discussed in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html. In order to refer to external types stored in split DWARF (dwo) objects, such as clang modules, we need to emit skeleton CUs, which identify the dwarf object (i.e., the clang module) by filename (the SplitDebugFilename) and a hash value, the dwo_id. This patch only contains the IR changes. The idea is that a CUs with a non-zero dwo_id field will be emitted together with a DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id attribute. http://reviews.llvm.org/D9488 rdar://problem/20091852 llvm-svn: 237949
* [opaque pointer type] Use the value type of the GlobalVariable rather than ↵David Blaikie2015-05-131-1/+1
| | | | | | accessing it through the pointee's type llvm-svn: 237312
* [opaque pointer type] Pass the explicit function type down to the ↵David Blaikie2015-05-131-1/+1
| | | | | | instruction constructor when parsing invoke instructions llvm-svn: 237273
* [opaque pointer type] Pass GlobalAlias the actual pointer type rather than ↵David Blaikie2015-04-291-4/+2
| | | | | | | | | | | | | decomposing it into pointee type + address space Many of the callers already have the pointer type anyway, and for the couple of callers that don't it's pretty easy to call PointerType::get on the pointee type and address space. This avoids LLParser from using PointerType::getElementType when parsing GlobalAliases from IR. llvm-svn: 236160
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-83/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
* IR: Add assembly/bitcode support for function metadata attachmentsDuncan P. N. Exon Smith2015-04-241-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+5
| | | | | | | | 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-5/+14
| | | | | | Make the code reusable for `Function` metadata attachments (PR23340). llvm-svn: 235778
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-04-241-6/+4
| | | | | | | | | | the invoke instruction Same as r235145 for the call instruction - the justification, tradeoffs, etc are all the same. The conversion script worked the same without any false negatives (after replacing 'call' with 'invoke'). llvm-svn: 235755
* Recommit r235458: [opaque pointer type] Avoid using ↵David Blaikie2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PointerType::getElementType for a few cases of CallInst (reverted in r235533) Original commit message: "Calls to llvm::Value::mutateType are becoming extra-sensitive now that instructions have extra type information that will not be derived from operands or result type (alloca, gep, load, call/invoke, etc... ). The special-handling for mutateType will get more complicated as this work continues - it might be worth making mutateType virtual & pushing the complexity down into the classes that need special handling. But with only two significant uses of mutateType (vectorization and linking) this seems OK for now. Totally open to ideas/suggestions/improvements, of course. With this, and a bunch of exceptions, we can roundtrip an indirect call site through bitcode and IR. (a direct call site is actually trickier... I haven't figured out how to deal with the IR deserializer's lazy construction of Function/GlobalVariable decl's based on the type of the entity which means looking through the "pointer to T" type referring to the global)" The remapping done in ValueMapper for LTO was insufficient as the types weren't correctly mapped (though I was using the post-mapped operands, some of those operands might not have been mapped yet so the type wouldn't be post-mapped yet). Instead use the pre-mapped type and explicitly map all the types. llvm-svn: 235651
* Revert "[opaque pointer type] Avoid using PointerType::getElementType for a ↵David Blaikie2015-04-221-1/+1
| | | | | | | | | | | few cases of CallInst" This reverts commit r235458. It looks like this might be breaking something LTO-ish. Looking into it & will recommit with a fix/test case/etc once I've got more to go on. llvm-svn: 235533
OpenPOWER on IntegriCloud