summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/GCMetadataPrinter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-06-071-3/+4
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 304954
* Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-08-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a registry" This differs from the previous version by being more careful about template instantiation/specialization in order to prevent errors when building with clang -Werror. Specifically: * begin is not defined in the template and is instead instantiated when Head is. I think the warning when we don't do that is wrong (PR28815) but for now at least do it this way to avoid the warning. * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY instead provide a template definition then do explicit instantiation. No compiler I've tried has problems with doing it the other way, but strictly speaking it's not permitted by the C++ standard so better safe than sorry. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 277806
* Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-281-2/+0
| | | | | | | | | registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. llvm-svn: 277008
* Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-07-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a registry" This version has two fixes compared to the original: * In Registry.h the template static members are instantiated before they are used, as clang gives an error if you do it the other way around. * The use of the Registry template in clang-tidy is updated in the same way as has been done everywhere else. Original commit message: Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. llvm-svn: 276973
* Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-271-2/+0
| | | | | | | | registry" This is causing a huge pile of buildbot failures. llvm-svn: 276857
* Adjust Registry interface to not require plugins to export a registryJohn Brawn2016-07-271-0/+2
| | | | | | | | | | | | | | | | | | | | Currently the Registry class contains the vestiges of a previous attempt to allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a plugin would have its own copy of a registry and export it to be imported by the tool that's loading the plugin. This only works if the plugin is entirely self-contained with the only interface between the plugin and tool being the registry, and in particular this conflicts with how IR pass plugins work. This patch changes things so that instead the add_node function of the registry is exported by the tool and then imported by the plugin, which solves this problem and also means that instead of every plugin having to export every registry they use instead LLVM only has to export the add_node functions. This allows plugins that use a registry to work on Windows if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used. Differential Revision: http://reviews.llvm.org/D21385 llvm-svn: 276856
* Revert 258157Philip Reames2016-01-191-4/+0
| | | | | | According the build bots, clang is using the Registry class somewhere as well. Will reapply with appropriate clang changes at a later point. llvm-svn: 258159
* [GC] Registry initialization and linkage interactionsPhilip Reames2016-01-191-0/+4
| | | | | | | | | | | | | | The Registry class constructs a linked list of nodes whose storage is inside static variables and nodes are added via static initializers. The trick is that those static initializers are in both the LLVM code base, and some random plugin that might get loaded in at runtime. The existing code tries to use C++ templates and their ODR rules to get a single definition of the registry for each type, but, experimentally, this doesn't quite work as designed. (Well, the entire structure doesn't. It might not actually be an ODR problem.) Previously, when I tried moving the GCStrategy class (along with it's registry) from CodeGen to IR, I ran into a problem where asking the GCStrategyRegistry a question would return inconsistent results depending on whether you asked from CodeGen (where the static initializers still were) or Transforms. My best guess is that this is a result of either a) an order of initialization error, or b) we ended up with two copies of the registry being created. I remember at the time having convinced myself it was probably (b), but I don't have any of my notes around from that investigation any more. See http://reviews.llvm.org/rL226311 for the original patch in question. This patch tries to remove the possibility of (b) above. (a) was already fixed in change 258109. Differential Revision: http://reviews.llvm.org/D16170 llvm-svn: 258157
* clang-format all the GC related files (NFC)Philip Reames2015-01-161-2/+2
| | | | | | Nothing interesting here... llvm-svn: 226342
* GCStrategy should not own GCFunctionInfoPhilip Reames2014-12-111-8/+0
| | | | | | | | | | | | This change moves the ownership and access of GCFunctionInfo (the object which describes the safepoints associated with a safepoint under GCRoot) to GCModuleInfo. Previously, this was owned by GCStrategy which was in turned owned by GCModuleInfo. This made GCStrategy module specific which is 'surprising' given it's name and other purposes. There's a few more changes needed, but we're getting towards the point we can reuse GCStrategy for gc.statepoint as well. p.s. The style of this code ends up being a mess. I was trying to move code around without otherwise changing much. Once I get the ownership structure rearranged, I will go through and fixup spacing, naming, comments etc. Differential Revision: http://reviews.llvm.org/D6587 llvm-svn: 223994
* Remove the Module pointer from GCStrategy and GCMetadataPrinterPhilip Reames2014-12-091-2/+2
| | | | | | | | | | | | | | | | In the current implementation, GCStrategy is a part of the ownership structure for the gc metadata which describes a Module. It also contains a reference to the module in question. As a result, GCStrategy instances are essentially Module specific. I plan to transition away from this design. Instead, a GCStrategy will be owned by the LLVMContext. It will be a lightweight policy object which contains no information about the Modules or Functions involved, but can be easily reached given a Function. The first step in this transition is to remove the direct Module reference from GCStrategy. This also requires removing the single user of this reference, the GCMetadataPrinter hierarchy. In theory, this will allow the lifetime of the printers to be scoped to the LLVMContext as well, but in practice, I'm not actually changing that. (Yet?) An alternate design would have been to move the direct Module reference into the GCMetadataPrinter and change the keying of the owning maps to explicitly key off both GCStrategy and Module. I'm open to doing it that way instead, but didn't see much value in preserving the per Module association for GCMetadataPrinters. The next change in this sequence will be to start unwinding the intertwined ownership between GCStrategy, GCModuleInfo, and GCFunctionInfo. Differential Revision: http://reviews.llvm.org/D6566 llvm-svn: 223859
* mcize the gc metadata printing stuff.Chris Lattner2010-04-041-4/+2
| | | | llvm-svn: 100324
* Remove pointless forward declaration, MSVC got confused by this.Benjamin Kramer2010-03-141-1/+0
| | | | llvm-svn: 98519
* switch GC_LABEL to use an MCSymbol operand instead of a label ID operand.Chris Lattner2010-03-141-1/+1
| | | | llvm-svn: 98474
* rename TAI -> MAI, being careful not to make MAILJMP instructions :)Chris Lattner2009-08-221-2/+2
| | | | llvm-svn: 79777
* Rename TargetAsmInfo (and its subclasses) to MCAsmInfo.Chris Lattner2009-08-221-2/+2
| | | | llvm-svn: 79763
* Use raw_ostream throughout the AsmPrinter.Owen Anderson2008-08-211-2/+2
| | | | llvm-svn: 55092
* Don't require Registry specializations to define random static variables.Gordon Henriksen2008-08-171-11/+0
| | | | llvm-svn: 54902
* Rename some GC classes so that their roll will hopefully be clearer.Gordon Henriksen2008-08-171-4/+14
| | | | | | | | | | | | | | | | | | In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC (setGC, hasGC, clearGC) Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. llvm-svn: 54899
* Factor GC metadata table assembly generation out of Collector in preparation ↵Gordon Henriksen2008-08-171-0/+31
for splitting AsmPrinter into its own library. llvm-svn: 54881
OpenPOWER on IntegriCloud