Commit Graph

8 Commits

Author SHA1 Message Date
Philip Reames
f8225ab80f Extend some comments around GCModuleInfo, GCFunctionInfo, & GCStrategy
Nothing particularly interesting here, just documenting the way the code currently works before I start changing it...



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:30:11 +00:00
Philip Reames
3490d23337 Remove the Module pointer from GCStrategy and GCMetadataPrinter
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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223859 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:57:54 +00:00
David Blaikie
3229c698e4 Use unique_ptr to manage ownership of GCFunctionInfos in GCStrategy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206249 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-15 06:07:26 +00:00
Dmitri Gribenko
77592fe39c Convert comments to proper Doxygen comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158248 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-09 00:01:45 +00:00
Nicolas Geoffray
7b8c2f8587 Add a custom safepoint method, in order for language implementers to decide which machine instruction gets to be a safepoint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144399 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-11 18:32:52 +00:00
Dan Gohman
d68a07650c Tidy up #includes, deleting a bunch of unnecessary #includes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61715 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05 17:59:02 +00:00
Gordon Henriksen
5eca075b74 Rename some GC classes so that their roll will hopefully be clearer.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54899 91177308-0d34-0410-b5e6-96231b3b80d8
2008-08-17 18:44:35 +00:00
Gordon Henriksen
5a29c9eed1 Factor GC metadata table assembly generation out of Collector in preparation for splitting AsmPrinter into its own library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54881 91177308-0d34-0410-b5e6-96231b3b80d8
2008-08-17 12:56:54 +00:00