summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* [PM] Fix a compile error with GCC. NFC.Chandler Carruth2016-08-191-2/+2
| | | | llvm-svn: 279228
* [PM] Make the the new pass manager support fully generic extra argumentsChandler Carruth2016-08-191-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to run methods, both for transform passes and analysis passes. This also allows the analysis manager to use a different set of extra arguments from the pass manager where useful. Consider passes over analysis produced units of IR like SCCs of the call graph or loops. Passes of this nature will often want to refer to the analysis result that was used to compute their IR units (the call graph or LoopInfo). And for transformations, they may want to communicate special update information to the outer pass manager. With this change, it becomes possible to have a run method for a loop pass that looks more like: PreservedAnalyses run(Loop &L, AnalysisManager<Loop, LoopInfo> &AM, LoopInfo &LI, LoopUpdateRecord &UR); And to query the analysis manager like: AM.getResult<MyLoopAnalysis>(L, LI); This makes accessing the known-available analyses convenient and clear, and it makes passing customized data structures around easy. My initial use case is going to be in updating the pass manager layers when the analysis units of IR change. But there are more use cases here such as having a layer that lets inner passes signal whether certain additional passes should be run because of particular simplifications made. Two desires for this have come up in the past: triggering additional optimization after successfully unrolling loops, and triggering additional inlining after collapsing indirect calls to direct calls. Despite adding this layer of generic extensibility, the *only* change to existing, simple usage are for places where we forward declare the AnalysisManager template. We really shouldn't be doing this because of the fragility exposed here, but currently it makes coping with the legacy PM code easier. Differential Revision: http://reviews.llvm.org/D21462 llvm-svn: 279227
* Support the DW_AT_noreturn DWARF flag.Adrian Prantl2016-08-171-2/+3
| | | | | | | | | | | This is used to mark functions with the C++11 [[ noreturn ]] or C11 _Noreturn attributes. Patch by Victor Leschuk! https://reviews.llvm.org/D23167 llvm-svn: 278940
* Add support to paternmatch for simple const Value cases.Pete Cooper2016-08-121-0/+27
| | | | | | | | | | | | | Pattern match has some paths which can operate on constant instructions, but not all. This adds a version of m_value() to return const Value* and changes ICmp matching to use auto so that it can match both constant and mutable instructions. Tests also included for both mutable and constant ICmpInst matching. This will be used in a future commit to constify ValueTracking.cpp. llvm-svn: 278570
* IR: Drop uniquing when an MDNode Value operand is deletedDuncan P. N. Exon Smith2016-08-031-2/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR28697. An MDNode can indirectly refer to a GlobalValue, through a ConstantAsMetadata. When the GlobalValue is deleted, the MDNode operand is reset to `nullptr`. If the node is uniqued, this can lead to a hard-to-detect cache invalidation in a Metadata map that's shared across an LLVMContext. Consider: 1. A map from Metadata* to `T` called RemappedMDs. 2. A node that references a global variable, `!{i1* @GV}`. 3. Insert `!{i1* @GV} -> SomeT` in the map. 4. Delete `@GV`, leaving behind `!{null} -> SomeT`. Looking up the generic and uninteresting `!{null}` gives you `SomeT`, which is likely related to `@GV`. Worse, `SomeT`'s lifetime may be tied to the deleted `@GV`. This occurs in practice in the shared ValueMap used since r266579 in the IRMover. Other code that handles more than one Module (with different lifetimes) in the same LLVMContext could hit it too. The fix here is a partial revert of r225223: in the rare case that an MDNode operand is a ConstantAsMetadata (i.e., wrapping a node from the Value hierarchy), drop uniquing if it gets replaced with `nullptr`. This changes step #4 above to leave behind `distinct !{null} -> SomeT`, which can't be confused with the generic `!{null}`. In theory, this can cause some churn in the LLVMContext's MDNode uniquing map when Values are being deleted. However: - The number of GlobalValues referenced from uniqued MDNodes is expected to be quite small. E.g., the debug info metadata schema only references GlobalValues from distinct nodes. - Other Constants have the lifetime of the LLVMContext, whose teardown is careful to drop references before deleting the constants. As a result, I don't expect a compile time regression from this change. llvm-svn: 277625
* Fix warnings in FunctionTest.cpp.Justin Lebar2016-07-131-6/+12
| | | | | | | | | | | | | Because of the goop involved in the EXPECT_EQ macro, we were getting the following warning expression with side effects has no effect in an unevaluated context because the "I++" was being used inside of a template type: switch (0) case 0: default: if (const ::testing::AssertionResult gtest_ar = (::testing::internal:: EqHelper<(sizeof(::testing::internal::IsNullLiteralHelper(Args[I++])) == 1)>::Compare("Args[I++]", "&A", Args[I++], &A))) ; else ::testing::internal::AssertHelper(::testing::TestPartResult::kNonFatalFailure, "../src/unittests/IR/FunctionTest.cpp", 94, gtest_ar.failure_message()) = ::testing::Message(); llvm-svn: 275291
* [codeview] Add DISubprogram::ThisAdjustmentReid Kleckner2016-07-011-59/+63
| | | | | | | | | | | | | | | | | | | | | Summary: This represents the adjustment applied to the implicit 'this' parameter in the prologue of a virtual method in the MS C++ ABI. The adjustment is always zero unless multiple inheritance is involved. This increases the size of DISubprogram by 8 bytes, unfortunately. The adjustment really is a signed 32-bit integer. If this size increase is too much, we could probably win it back by splitting out a subclass with info specific to virtual methods (virtuality, vindex, thisadjustment, containingType). Reviewers: aprantl, dexonsmith Subscribers: aaboud, amccarth, llvm-commits Differential Revision: http://reviews.llvm.org/D21614 llvm-svn: 274325
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-211-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
* [PM] Run clang-format over various parts of the new pass manager codeChandler Carruth2016-06-171-2/+2
| | | | | | | prior to some very substantial patches to isolate any formatting-only changes. llvm-svn: 272991
* [PM] Remove support for omitting the AnalysisManager argument to newChandler Carruth2016-06-171-3/+5
| | | | | | | | | | | | | | | | | | | | pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
* [DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner2016-06-081-8/+23
| | | | | | | | | | | | | | | | | | | | | Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
* Verifier: Simplify and fix issue where we were not verifying unmaterialized ↵Peter Collingbourne2016-06-061-0/+5
| | | | | | | | | | | | | | functions. Arrange to call verify(Function &) on each function, followed by verify(Module &), whether the verifier is being used from the pass or from verifyModule(). As a side effect, this fixes an issue that caused us not to call verify(Function &) on unmaterialized functions from verifyModule(). Differential Revision: http://reviews.llvm.org/D21042 llvm-svn: 271956
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-26/+0
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Port the strip-invalid-debuginfo logic to the legacy verifier pass, too.Adrian Prantl2016-05-251-1/+23
| | | | | | | | | | | | | | | | | | | | | Since r268966 the modern Verifier pass defaults to stripping invalid debug info in nonasserts builds. This patch ports this behavior back to the legacy Verifier pass as well. The primary motivation is that the clang frontend accepts bitcode files as input but is still using the legacy pass pipeline. Background: The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D20629 <rdar://problem/26448800> llvm-svn: 270768
* Fix constant folding of addrspacecast of nullMatt Arsenault2016-05-211-0/+21
| | | | | | | This should not be making assumptions on the value of the casted pointer. llvm-svn: 270293
* [ConstantRange] Add an getEquivalentICmp helperSanjoy Das2016-05-191-0/+46
| | | | | | | Currently only its unit test uses it, but this will be used in a later change to simplify some logic in the GuardWidening pass. llvm-svn: 270018
* Delete duplicated verifier test.Rafael Espindola2016-05-111-0/+27
| | | | | | Also add unittest to show we still detect the errors. llvm-svn: 269182
* Disable this unit test on MSVC, which crashes while compiling it.Adrian Prantl2016-05-091-1/+3
| | | | llvm-svn: 268985
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
* Revert "Separate the Verifier into an analysis and a transformation pass and"Adrian Prantl2016-05-091-25/+0
| | | | | | This reverts commit 268937 while investigating build bot breakage. llvm-svn: 268939
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 llvm-svn: 268937
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-34/+30
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* Add #ifndef NDEBUG markers around EXPECT_DEATH after r267270Duncan P. N. Exon Smith2016-04-231-0/+2
| | | | | | http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/36076 llvm-svn: 267275
* BitcodeReader: Avoid referencing unresolved nodes from distinct onesDuncan P. N. Exon Smith2016-04-231-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each reference to an unresolved MDNode is expensive, since the RAUW support in MDNode uses a separate allocation and side map. Since a distinct MDNode doesn't require its operands on creation (unlike uniuqed nodes, there's no need to check for structural equivalence), use nullptr for any of its unresolved operands. Besides reducing the burden on MDNode maps, this can avoid allocating temporary MDNodes in the first place. We need some way to track operands. Invent DistinctMDOperandPlaceholder for this purpose, which is a Metadata subclass that holds an ID and points at its single user. DistinctMDOperandPlaceholder::replaceUseWith is just like RAUW, but its name highlights that there is only ever exactly one use. There is no support for moving (or, obviously, copying) these. Move support would be possible but expensive; leaving it unimplemented prevents user error. In the BitcodeReader I originally considered allocating on a BumpPtrAllocator and keeping a vector of pointers to them, and then I realized that std::deque implements exactly this. A couple of obvious follow-ups: - Change ValueEnumerator to emit distinct nodes first to take more advantage of this optimization. (How convenient... I think I might have a couple of patches for this.) - Change DIBuilder and its consumers (like CGDebugInfo in clang) to use something like this when constructing debug info in the first place. llvm-svn: 267270
* Tag the end of an anonymous namespace, NFCDuncan P. N. Exon Smith2016-04-231-1/+1
| | | | | | Prevent clang-format from moving the closing branch. llvm-svn: 267269
* IR: Enable debug info type ODR uniquing for forward declsDuncan P. N. Exon Smith2016-04-191-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | Add a new method, DICompositeType::buildODRType, that will create or mutate the DICompositeType for a given ODR identifier, and use it in LLParser and BitcodeReader instead of DICompositeType::getODRType. The logic is as follows: - If there's no node, create one with the given arguments. - Else, if the current node is a forward declaration and the new arguments would create a definition, mutate the node to match the new arguments. - Else, return the old node. This adds a missing feature supported by the current DITypeIdentifierMap (which I'm slowly making redudant). The only remaining difference is that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas DICompositeType::buildODRType has a "the-first-one-wins" rule. For now I'm leaving behind DICompositeType::getODRType since it has obvious, low-level semantics that are convenient for unit testing. llvm-svn: 266786
* IR: LLVMContextTest => DebugTypeODRUniquingTest, NFCDuncan P. N. Exon Smith2016-04-192-4/+4
| | | | | | | | | The second test in this file is actually testing DICompositeType API, not LLVMContext API (after r266742 moved it to a higher level). This really doesn't make sense in an LLVMContextTest. Rename the tests before adding more. llvm-svn: 266764
* IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFCDuncan P. N. Exon Smith2016-04-191-17/+23
| | | | | | | | | | | | | | Lift the API for debug info ODR type uniquing up a layer. Instead of clients managing the map directly on the LLVMContext, add a static method to DICompositeType called getODRType and handle the map in the background. Also adds DICompositeType::getODRTypeIfExists, so far just for convenience in the unit tests. This simplifies the logic in LLParser and BitcodeReader. Because of argument spam there are actually a few more lines of code now; I'll see if I come up with a reasonable way to clean that up. llvm-svn: 266742
* IR: Require DICompositeType for ODR uniquing type mapDuncan P. N. Exon Smith2016-04-191-5/+7
| | | | | | | | Tighten up the API for debug info ODR type uniquing in LLVMContext. The only reason to allow other DIType subclasses is to make the unit tests prettier :/. llvm-svn: 266737
* IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith2016-04-191-15/+15
| | | | | | | | | | | As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes llvm-svn: 266713
* [NFC] Header cleanupMehdi Amini2016-04-182-2/+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
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-172-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* [DebugInfo] Correct the assertion introduced in r266509 + update test.Davide Italiano2016-04-161-1/+2
| | | | llvm-svn: 266512
* [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl2016-04-151-37/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-1413-263/+312
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* [DebugInfo] Optimize memory layout of DISubprogram.Davide Italiano2016-04-131-2/+3
| | | | | | | | | | | | | | | A DISubprogram on x86_64 was 48 bytes. During an LTO build we end up allocating *a lot* of these (see Duncan's numbers on llvm-dev and/or my numbers in the review link). This change reduces the size to 40 bytes, with a nice effect on peak memory usage when LTO'ing clang. There are more classes in the hierarchy which can be compacted so more patches will come. DISubprogram was the biggest offender in my profiling, anyway. Differential Revision: http://reviews.llvm.org/D18918 llvm-svn: 266241
* IRMover: Steal arguments when moving functions, NFCDuncan P. N. Exon Smith2016-04-062-0/+107
| | | | | | | | | | | | | | | | | | Instead of copying arguments from the source function to the destination, steal them. This has a few advantages. - The ValueMap doesn't need to be seeded with (or cleared of) Arguments. - Often the destination function won't have created any arguments yet, so this avoids malloc traffic. - Argument names don't need to be copied. Because argument lists are lazy, this required a new Function::stealArgumentListFrom helper. llvm-svn: 265519
* Fix non-determinism in order of LLVM attributesReid Kleckner2016-04-041-0/+9
| | | | | | | | | | | | | | | | | | We were using array_pod_sort on an array of type 'Attribute', which wraps a pointer to AttributeImpl. For the most part this didn't matter because the printing code prints enum attributes in a defined order, but integer attributes such as 'align' and 'dereferenceable' were not ordered. Furthermore, AttributeImpl::operator< was broken for integer attributes. An integer attribute is a kind and an integer value, and both pieces need to be compared. By fixing the comparison operator, we can go back to std::sort, and things look good now. This should fix clang arm-swiftcall.c test failures on Windows. llvm-svn: 265361
* Document end of anonymous namespaces, NFCDuncan P. N. Exon Smith2016-04-021-1/+1
| | | | | | Prevent clang-format from deleting the preceding newline. llvm-svn: 265227
* Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl2016-03-311-2/+2
| | | | | | | | | | | | | This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
* [ThinLTO] Remove post-pass metadata linking supportTeresa Johnson2016-03-291-14/+0
| | | | | | | | | | | Since we have moved to a model where functions are imported in bulk from each source module after making summary-based importing decisions, there is no longer a need to link metadata as a postpass, and all users have been removed. This essentially reverts r255909 and follow-on fixes. llvm-svn: 264763
* Remove some unused variablesDavid Blaikie2016-03-131-5/+4
| | | | llvm-svn: 263396
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-132-2/+2
| | | | | | | | This reapplies r263258, which was reverted in r263321 because of issues on Clang side. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263393
* Fixed DIBuilder to verify that same imported entity will not be added twice ↵Amjad Aboud2016-03-131-0/+15
| | | | | | | | to the "imports" list of the DICompileUnit. Differential Revision: http://reviews.llvm.org/D17884 llvm-svn: 263379
* Temporarily revert:Eric Christopher2016-03-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ae14bf6488e8441f0f6d74f00455555f6f3943ac Author: Mehdi Amini <mehdi.amini@apple.com> Date: Fri Mar 11 17:15:50 2016 +0000 Remove PreserveNames template parameter from IRBuilder Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263258 91177308-0d34-0410-b5e6-96231b3b80d8 until we can figure out what to do about clang and Release build testing. This reverts commit 263258. llvm-svn: 263321
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-112-2/+2
| | | | | | | | | | | | | | | Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263258
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-9/+9
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* [PM] Rename the CRTP mixin base classes for the new pass manager toChandler Carruth2016-03-111-9/+11
| | | | | | | | | | | | | | | | | | | | clarify their purpose. Firstly, call them "...Mixin" types so it is clear that there is no type hierarchy being formed here. Secondly, use the term 'Info' to clarify that they aren't adding any interesting *semantics* to the passes or analyses, just exposing APIs used by the management layer to get information about the pass or analysis. Thanks to Manuel for helping pin down the naming confusion here and come up with effective names to address it. In case you already have some out-of-tree stuff, the following should be roughly what you want to update: perl -pi -e 's/\b(Pass|Analysis)Base\b/\1InfoMixin/g' llvm-svn: 263217
* [PM] Implement the final conclusion as to how the analysis IDs shouldChandler Carruth2016-03-111-0/+10
| | | | | | | | | | | | | | | | | | | | work in the face of the limitations of DLLs and templated static variables. This requires passes that use the AnalysisBase mixin provide a static variable themselves. So as to keep their APIs clean, I've made these private and befriended the CRTP base class (which is the common practice). I've added documentation to AnalysisBase for why this is necessary and at what point we can go back to the much simpler system. This is clearly a better pattern than the extern template as it caught *numerous* places where the template magic hadn't been applied and things were "just working" but would eventually have broken mysteriously. llvm-svn: 263216
* [ConstantRange] Rename test; NFCSanjoy Das2016-03-031-1/+1
| | | | llvm-svn: 262640
OpenPOWER on IntegriCloud