riscv-gnu-toolchain/llvm.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
2014-12-11	GCStrategy should not own GCFunctionInfo	Philip Reames	1	-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
2014-12-09	Remove the Module pointer from GCStrategy and GCMetadataPrinter	Philip Reames	1	-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
2010-04-04	mcize the gc metadata printing stuff.	Chris Lattner	1	-4/+2
	llvm-svn: 100324
2010-03-14	Remove pointless forward declaration, MSVC got confused by this.	Benjamin Kramer	1	-1/+0
	llvm-svn: 98519
2010-03-14	switch GC_LABEL to use an MCSymbol operand instead of a label ID operand.	Chris Lattner	1	-1/+1
	llvm-svn: 98474
2009-08-22	rename TAI -> MAI, being careful not to make MAILJMP instructions :)	Chris Lattner	1	-2/+2
	llvm-svn: 79777
2009-08-22	Rename TargetAsmInfo (and its subclasses) to MCAsmInfo.	Chris Lattner	1	-2/+2
	llvm-svn: 79763
2008-08-21	Use raw_ostream throughout the AsmPrinter.	Owen Anderson	1	-2/+2
	llvm-svn: 55092
2008-08-17	Don't require Registry specializations to define random static variables.	Gordon Henriksen	1	-11/+0
	llvm-svn: 54902
2008-08-17	Rename some GC classes so that their roll will hopefully be clearer.	Gordon Henriksen	1	-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
2008-08-17	Factor GC metadata table assembly generation out of Collector in preparation ↵	Gordon Henriksen	1	-0/+31
	for splitting AsmPrinter into its own library. llvm-svn: 54881