summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Linker
Commit message (Collapse)AuthorAgeFilesLines
* IR Linking: Support merging Warning+Max module metadata flagsDavid Blaikie2020-02-111-23/+47
| | | | | | | | | | | | | | | | | Summary: Debug Info Version was changed to use "Max" instead of "Warning" per the original design intent - but this maxes old/new IR unlinkable, since mismatched merge styles are a linking failure. It seems possible/maybe reasonable to actually support the combination of these two flags: Warn, but then use the maximum value rather than the first value/earlier module's value. Reviewers: tejohnson Differential Revision: https://reviews.llvm.org/D74257 (cherry picked from commit ba9cae58bbdd41451ee67773c9d0f90a01756f12)
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-011-1/+1
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [IRMover] Set Address Space for moved global valuesTeresa Johnson2019-11-051-4/+5
| | | | | | | | | | | | | | | | | | | Summary: Set Address Space when creating a new function (from another). Fix PR41154. Patch by Ehud Katz <ehudkatz@gmail.com> Reviewers: tejohnson, chandlerc Reviewed By: tejohnson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69361
* [IRMover] Use GlobalValue::getAddressSpace instead of directly from its type ↵Teresa Johnson2019-11-051-10/+10
| | | | | | | | | | | | | | | | | | [NFC] Summary: Change the old form of G->getType()->getAddressSpace() to the new G->getAddressSpace() (underneath does the same). Patch by Ehud Katz <ehudkatz@gmail.com> Reviewers: tejohnson, chandlerc Reviewed By: tejohnson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69550
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-152-2/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* [IRMover] Don't map globals if their types are the samePirama Arumuga Nainar2019-09-111-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: During IR Linking, if the types of two globals in destination and source modules are the same, it can only be because the global in the destination module is originally from the source module and got added to the destination module from a shared metadata. We shouldn't map this type to itself in case the type's components get remapped to a new type from the destination (for instance, during the loop over SrcM->getIdentifiedStructTypes() further below in IRLinker::computeTypeMapping()). Fixes PR40312. Reviewers: tejohnson, pcc, srhines Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66814 llvm-svn: 371643
* Linker: Add support for GlobalIFunc.Peter Collingbourne2019-08-081-43/+55
| | | | | | | | | | GlobalAlias and GlobalIFunc ought to be treated the same by the IR linker, so we can generalize the code to be in terms of their common base class GlobalIndirectSymbol. Differential Revision: https://reviews.llvm.org/D55046 llvm-svn: 368357
* Reapply: IR: add optional type to 'byval' function parametersTim Northover2019-05-301-0/+20
| | | | | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
* [IRMover] Improve diagnostic messages for conflicting metadataIgor Kudrin2019-05-161-3/+9
| | | | | | | | | | | | This does the similar for error messages as rL344011 has done for warnings. With llvm::lto::LTO, the error might appear when LTO::run() is executed. In that case, the calling code cannot know which module causes the error and, subsequently, cannot hint the user. Differential Revision: https://reviews.llvm.org/D61880 llvm-svn: 360857
* [Linker] Fix crash handling appending linkageRafael Auler2019-03-201-5/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When linking two llvm.used arrays, if the resulting merged array ends up with duplicated elements (with the same name) but with different types, the IRLinker was crashing. This was supposed to be legal, as the IRLinker bitcasts elements to match types in these situations. This bug was exposed by D56928 in clang to support attribute used in member functions of class templates. Crash happened when self-hosting with LTO. Since LLVM depends on attribute used to generate code for the dump() method, ubiquitous in the code base, many input bc had a definition of this method referenced in their llvm.used array. Some of these classes got optimized, changing the type of the first parameter (this) in the dump method, leading to a scenario with a pool of valid definitions but some with a different type, triggering this bug. This is a memory bug: ValueMapper depends on (calls) the materializer provided by IRLinker, and this materializer was freely calling RAUW methods whenever a global definition was updated in the temporary merged output file. However, replaceAllUsesWith may or may not destroy constants that use this global. If the linked definition has a type mismatch regarding the new def and the old def, the materializer would bitcast the old type to the new type and the elements of the llvm.used array, which already uses bitcast to i8*, would end up with elements cascading two bitcasts. RAUW would then indirectly call the constantfolder to update the constant to the new ref, which would, instead of updating the constant, destroy it to be able to create a new constant that folds the two bitcasts into one. The problem is that ValueMapper works with pointers to the same constants that may be getting destroyed by RAUW. Obviously, RAUW can update references in the Module to do not use the old destroyed constant, but it can't update ValueMapper's internal pointers to these constants, which are now invalid. The approach here is to move the task of RAUWing old definitions outside of the materializer. Test Plan: Added LIT test case, tested clang self-hosting with D56928 and verified it works Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D59552 llvm-svn: 356597
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-194-16/+12
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* ThinLTO: Do not import debug info for imported global constantsDavid Blaikie2018-12-051-0/+10
| | | | | | | | | | | | | | | | | | | | It looks like this isn't necessary (in any tests I've done, it results in the global being described with no location or value in the imported side - while it's still fully described in the place it's imported from) & results in significant/pathological debug info growth to home these location-less global variable descriptions on the import side. This is a rather pressing/important issue to address - this regressed executable size for one example I'm looking at by 15%, object size is probably similar though I haven't measured it, and a 22x increase in the number of CUs in the cu_index in split DWARF DWP files, creating a similarly large regression in the time it takes llvm-symbolizer to run on such binaries. Reviewers: tejohnson, evgeny777 Differential Revision: https://reviews.llvm.org/D55309 llvm-svn: 348416
* [ThinLTO] Internalize readonly globalsEugene Leviant2018-11-161-5/+0
| | | | | | | | An attempt to recommit r346584 after failure on OSX build bot. Fixed cache key computation in ThinLTOCodeGenerator and added test case llvm-svn: 347033
* Revert "[ThinLTO] Internalize readonly globals"Steven Wu2018-11-131-0/+5
| | | | | | This reverts commit 10c84a8f35cae4a9fc421648d9608fccda3925f2. llvm-svn: 346768
* [ThinLTO] Internalize readonly globalsEugene Leviant2018-11-101-5/+0
| | | | | | | | | This patch allows internalising globals if all accesses to them (from live functions) are from non-volatile load instructions Differential revision: https://reviews.llvm.org/D49362 llvm-svn: 346584
* llvm-link: Improve diagnostic for module-level metadata mismatchDavid Blaikie2018-10-091-2/+8
| | | | | | | | | | | | This might produce hard to read/illegible diagnostics for especially weird/non-trivial module metadata but integers are about all we are using these days, so seems more useful than not. Patch based on work by Kristina Brooks - thanks! Differential Revision: https://reviews.llvm.org/D52952 llvm-svn: 344011
* Fix asserts when linking wrong address space declarationsMatt Arsenault2018-09-241-3/+6
| | | | llvm-svn: 342858
* [NFC] Remove an empty line.Xin Tong2018-07-271-1/+0
| | | | llvm-svn: 338104
* [LTO] Fix linking with an alias defined using another alias.Eli Friedman2018-07-131-1/+1
| | | | | | | | | | | | When we're linking an alias which will be defined later, we neeed to build a GlobalAlias, or else we'll crash later in IRLinker::linkGlobalValueBody. clang sometimes constructs aliases like this for C++ destructors. Differential Revision: https://reviews.llvm.org/D49316 llvm-svn: 337053
* IRMover: Account for matching types present across modulesVlad Tsyrklevich2018-06-201-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Due to uniqueing of DICompositeTypes, it's possible for a type from one module to be loaded into another earlier module without being renamed. Then when the defining module is being IRMoved, the type can be used as a Mapping destination before being loaded, such that when it's requested using TypeMapTy::get() it will fail with an assertion that the type is a source type when it's actually a type in both the source and destination modules. Correctly handle that case by allowing a non-opaque non-literal struct type be present in both modules. Fix for PR37684. Reviewers: pcc, tejohnson Reviewed By: pcc, tejohnson Subscribers: tobiasvk, mehdi_amini, steven_wu, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D47898 llvm-svn: 335145
* [ThinLTO] Recommit of import global variablesEugene Leviant2018-03-121-8/+4
| | | | | | | This wasreverted in r326638 due to link problems and fixed afterwards llvm-svn: 327254
* [ThinLTO] Revert r325320: Import global variablesChandler Carruth2018-03-021-4/+8
| | | | | | | | | | | | | | This caused some links to fail with ThinLTO due to missing symbols as well as causing some binaries to have failures at runtime. We're working with the author to get a test case, but want to get the tree green again. Further, it appears to introduce a data race. While the test usage of threads was disabled in r325361 & r325362, that isn't an acceptable fix. I've reverted both of these as well. This code needs to be thread safe. Test cases for this are already on the original commit thread. llvm-svn: 326638
* Revert "[IRMover] Implement name based structure type mapping"Rafael Espindola2018-02-211-14/+7
| | | | | | | | This reverts commit r325686. There was a misunderstanding and this has not been approved yet. llvm-svn: 325715
* [IRMover] Implement name based structure type mappingEugene Leviant2018-02-211-7/+14
| | | | | | Differential revision: https://reviews.llvm.org/D43199 llvm-svn: 325686
* [ThinLTO] Import global variablesEugene Leviant2018-02-161-8/+4
| | | | | | Differential revision: https://reviews.llvm.org/D43077 llvm-svn: 325320
* [IRMover] Move type name extraction to a separate function. NFCEugene Leviant2018-02-141-6/+11
| | | | llvm-svn: 325110
* [IRMover] Add comment and fix test caseEugene Leviant2018-01-251-0/+6
| | | | llvm-svn: 323407
* Fix crash when linking metadata with ODR type uniquingTeresa Johnson2018-01-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With DebugTypeODRUniquing enabled, during IR linking debug metadata in the destination module may be reached from the source module. This means that ConstantAsMetadata nodes (e.g. on DITemplateValueParameter) may contain a value the destination module. When trying to map such metadata nodes, we will attempt to map a GV already in the dest module. linkGlobalValueProto will end up with a source GV that is the same as the dest GV as well as the new GV. Trying to access the TypeMap for the source GV type, which is actually a dest GV type, hits an assertion since it appears that we have mapped into the source module (because the type is the value not a key into the map). Detect that we don't need to access the TypeMap in this case, since there is no need to create a bitcast from the new GV to the source GV type as they GV are the same. Fixes PR35722. Reviewers: mehdi_amini, pcc Subscribers: probinson, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D41624 llvm-svn: 322103
* Linker: Create a function declaration when moving a non-prevailing alias of ↵Peter Collingbourne2017-08-101-0/+4
| | | | | | | | | | | | | | function type. We were previously creating a global variable of function type, which is invalid IR. This issue was exposed by r304690, in which we started asserting that global variables were of a valid type. Fixes PR33462. Differential Revision: https://reviews.llvm.org/D36438 llvm-svn: 310543
* [Linker] PR33527 - Linker::LinkOnlyNeeded should import AppendingLinkage globalsBenoit Belley2017-08-091-2/+12
| | | | | | | | | | | Linker::LinkOnlyNeeded should always import globals with AppendingLinkage. This resolves PR33527. Differential Revision: https://reviews.llvm.org/D34448 llvm-svn: 310522
* [Linker] Add directives to support mixing ARM/Thumb module-level inline asm.Florian Hahn2017-07-121-2/+16
| | | | | | | | | | | | | | | | | | | | | | Summary: By prepending `.text .thumb .balign 2` to the module-level inline assembly from a Thumb module, the assembler will generate the assembly from that module as Thumb, even if the destination module uses an ARM triple. Similar directives are used for module-level inline assembly in ARM modules. The alignment and instruction set are reset based on the target triple before emitting the first function label. Reviewers: olista01, tejohnson, echristo, t.p.northover, rafael Reviewed By: echristo Subscribers: aemerson, javed.absar, eraman, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D34622 llvm-svn: 307772
* Support for taking the max of module flags when linking, use for PIE/PICTeresa Johnson2017-05-231-2/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: Add Max ModFlagBehavior, which can be used to take the max of two module flag values when merging modules. Use it for the PIE and PIC levels. This avoids an error when we try to import from a module built -fpic into a module built -fPIC, for example. For both PIE and PIC levels, this will be legal, since the code generation gets more conservative as the level is increased. Therefore we can take the max instead of somehow trying to block importing between modules compiled with different levels. Reviewers: tmsriram, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33418 llvm-svn: 303590
* [ThinLTO] Do not assert when adding a module with a different butAkira Hatanaka2017-05-181-23/+3
| | | | | | | | | | | | | | | | compatible target triple Currently, an assertion fails in ThinLTOCodeGenerator::addModule when the target triple of the module being added doesn't match that of the one stored in TMBuilder. This patch relaxes the constraint and makes changes to allow target triples that only differ in their version numbers on Apple platforms, similarly to what r228999 did. rdar://problem/30133904 Differential Revision: https://reviews.llvm.org/D33291 llvm-svn: 303326
* De-virtualize GlobalValueReid Kleckner2017-05-111-7/+11
| | | | | | | | | | | | | | | The erase/remove from parent methods now use a switch table to remove themselves from their appropriate parent ilist. The copyAttributesFrom method is now completely non-virtual, since we only ever copy attributes from a global of the appropriate type. Pre-requisite to de-virtualizing Value to save a vptr (https://reviews.llvm.org/D31261). NFC llvm-svn: 302823
* [Linker] Provide callback for internalizationJonas Devlieghere2017-03-131-19/+27
| | | | | | Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
* IRMover: Merge flags LinkModuleInlineAsm and IsPerformingImport.Peter Collingbourne2017-02-032-11/+11
| | | | | | | | | Currently these flags are always the inverse of each other, so there is no need to keep them separate. Differential Revision: https://reviews.llvm.org/D29471 llvm-svn: 294016
* ModuleLinker: Remove importing support. NFCI.Peter Collingbourne2017-02-031-58/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D29470 llvm-svn: 294015
* FunctionImport: Use IRMover directly.Peter Collingbourne2017-02-031-2/+1
| | | | | | | | | | | | The importer was previously using ModuleLinker in a sort of "IRMover mode". Use IRMover directly instead in order to remove a level of indirection. I will remove all importing support from ModuleLinker in a separate change. Differential Revision: https://reviews.llvm.org/D29468 llvm-svn: 294014
* Linker: Move special casing for available_externally in IRMover to clients. ↵Peter Collingbourne2017-02-022-4/+2
| | | | | | | | | | NFCI. The goal is to simplify the semantic model for clients of IRMover. Differential Revision: https://reviews.llvm.org/D29435 llvm-svn: 293864
* [ThinLTO] Import only necessary DICompileUnit fieldsTeresa Johnson2016-12-122-4/+75
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed on mailing list, for ThinLTO importing we don't need to import all the fields of the DICompileUnit. Don't import enums, macros, retained types lists. Also only import local scoped imported entities. Since we don't currently import any global variables, we also don't need to import the list of global variables (added an assert to verify none are being imported). This is being done by pre-populating the value map entries to map the unneeded metadata to nullptr. For the imported entities, we can simply replace the source module's list with a new list containing only those needed imported entities. This is done in the IRLinker constructor so that value mapping automatically does the desired mapping. Reviewers: mehdi_amini, dexonsmith, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27635 llvm-svn: 289441
* IR: Move NumElements field from {Array,Vector}Type to SequentialType.Peter Collingbourne2016-12-021-5/+3
| | | | | | | | | | Now that PointerType is no longer a SequentialType, all SequentialTypes have an associated number of elements, so we can move that information to the base class, allowing for a number of simplifications. Differential Revision: https://reviews.llvm.org/D27122 llvm-svn: 288464
* [ThinLTO] Fix crash when importing an opaque typeMehdi Amini2016-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It seems that because ThinLTO does not import the full module, some invariant of the type mapper are broken. In Monolithic LTO, we import every globals: when calling IRLinker::copyFunctionProto() on @foo(), we end-up calling TypeMapTy::get(FTy) on the type of @foo(), which will map %0 and record the destination as opaque. ThinLTO skips this because @foo is not imported and goes directly to the next stage. Next we call computeTypeMapping() that map the types for each globals, and ends up checking for type isomorphism, and may add type mapping. However it doesn't record if there was an opaque destination type that was resolved. Instead of lazily "discovering" opaque type in the destination module on the go, we change the TypeFinder to eagerly record all types and not only the named ones. Differential Revision: https://reviews.llvm.org/D26840 llvm-svn: 287453
* IRMover: Avoid accidentally mapping types from the destination module (PR30799)Hans Wennborg2016-11-181-0/+8
| | | | | | | | | | | | | | During Module linking, it's possible for SrcM->getIdentifiedStructTypes(); to return types that are actually defined in the destination module (DstM). Depending on how the bitcode file was read, getIdentifiedStructTypes() might do a walk over all values, including metadata nodes, looking for types. In my case, a debug info metadata node was shared between the two modules, and it referred to a type defined in the destination module (see test case). Differential Revision: https://reviews.llvm.org/D26212 llvm-svn: 287353
* Linker: Remove unnecessary call to copyMetadata in IRLinker::linkGlobalVariable.Peter Collingbourne2016-11-141-2/+0
| | | | | | | | | | | This was causing us to create duplicate metadata on global variables. Debug info test case by Adrian Prantl, additional test cases by me. Fixes PR31012. Differential Revision: https://reviews.llvm.org/D26622 llvm-svn: 286905
* TypoAdrian Prantl2016-11-141-1/+1
| | | | llvm-svn: 286845
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* Typo: nomed struct -> named structHans Wennborg2016-10-191-1/+1
| | | | llvm-svn: 284635
* [ThinLTO] Don't link module level assembly when importingTeresa Johnson2016-10-122-6/+16
| | | | | | | | | | | | | | | | | | | | | Module inline asm was always being linked/concatenated when running the IRLinker. This is correct for full LTO but not when we are importing for ThinLTO, as it can result in multiply defined symbols when the module asm defines a global symbol. In order to test with llvm-lto2, I had to work around PR30396, where a symbol that is defined in module assembly but defined in the LLVM IR appears twice. Added workaround to llvm-lto2 with a FIXME. Fixes PR30610. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25359 llvm-svn: 284030
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-131-3/+5
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
OpenPOWER on IntegriCloud