dragonegg/TODO - llvm-archive - Git at Google

 Build system
 ------------

 The location of the gcc source and objects should be passed as options to a
 configure script rather than being hardwired into the Makefile.

 Determination of the target triple should be moved from the Makefile to a
 configure script.

 The plugin revision is created from the subversion revision.  What if people
 are using git etc?  Maybe it should be calculated in a configure script, but
 since that might not get run often perhaps the Makefile is the best place.

 Target subdirectories should have their own Makefiles, instead of assuming
 that there's only one source file and that it's called llvm-target.cpp.

 Currently the target directory (eg: i386) is calculated from the target triple
 (eg: x86_64-unknown-linux-gnu) using gcc's config.gcc script.  This should be
 done from a configure script, rather from the Makefile using the get_arch_dir
 wrapper.

 The Makefile needs to know the LLVM target name (eg: x86) in order to pass it
 to llvm-config so as to get the libraries to link with for target codegen.
 This should be calculated in a configure script (presumably by a small program
 that uses the LLVM triple facilities to calculate it).  If we know this, then
 we might as well rename target directories like i386/ to x86/ instead, and
 eliminate use of gcc's config.gcc script.  This also means that LLVM_TARGET_NAME
 could be defined from the Makefile rather than being specified in llvm-target.h.
 Maybe LLVM_TARGET_INTRINSIC_PREFIX could go too.

 Teach the build system that the plugin needs to be rebuilt if any of the bits of
 LLVM/gcc it depends on changes.


 Memory management
 -----------------

 After we codegen them, GCC functions will be garbage collected if the garbage
 collector runs.  However the garbage collector is only run if lots of memory
 was allocated since the last run.  GCC doesn't know how much memory LLVM is
 allocating, so we may be allocating vast amounts of LLVM memory converting
 gimple into LLVM IR, but nonetheless the garbage collector won't free up GCC
 memory for us, even though there might be lots of memory to free.  Work out
 some way of teaching the garbage collector about the amount of memory allocated
 by LLVM.

 After recent changes to the lto tree, it looks like functions are no longer
 being garbage collected after they are codegened.  Investigate.


 Optimizations
 -------------

 After outputting global variables, maybe they can be deleted or marked somehow
 (eg: TREE_ASM_WRITTEN) so that GCC does not output them (such output gets sent
 to /dev/null, but it would be more efficient to teach GCC to not produce any in
 the first place).  Investigate.

 Consider having DECL_LLVM and friends store values for trees local to a
 function in a separate map that can be cleared once the function has been
 emitted.  Determining which trees are local (LABEL_DECL, VAR_DECL but not
 static etc) should be pretty quick, so the cost of routing to the right map
 should be insignificant, while having a much smaller map for globals could
 be a win.

 Consider using separate caches for types and globals.
	Build system
	------------

	The location of the gcc source and objects should be passed as options to a
	configure script rather than being hardwired into the Makefile.

	Determination of the target triple should be moved from the Makefile to a
	configure script.

	The plugin revision is created from the subversion revision. What if people
	are using git etc? Maybe it should be calculated in a configure script, but
	since that might not get run often perhaps the Makefile is the best place.

	Target subdirectories should have their own Makefiles, instead of assuming
	that there's only one source file and that it's called llvm-target.cpp.

	Currently the target directory (eg: i386) is calculated from the target triple
	(eg: x86_64-unknown-linux-gnu) using gcc's config.gcc script. This should be
	done from a configure script, rather from the Makefile using the get_arch_dir
	wrapper.

	The Makefile needs to know the LLVM target name (eg: x86) in order to pass it
	to llvm-config so as to get the libraries to link with for target codegen.
	This should be calculated in a configure script (presumably by a small program
	that uses the LLVM triple facilities to calculate it). If we know this, then
	we might as well rename target directories like i386/ to x86/ instead, and
	eliminate use of gcc's config.gcc script. This also means that LLVM_TARGET_NAME
	could be defined from the Makefile rather than being specified in llvm-target.h.
	Maybe LLVM_TARGET_INTRINSIC_PREFIX could go too.

	Teach the build system that the plugin needs to be rebuilt if any of the bits of
	LLVM/gcc it depends on changes.


	Memory management
	-----------------

	After we codegen them, GCC functions will be garbage collected if the garbage
	collector runs. However the garbage collector is only run if lots of memory
	was allocated since the last run. GCC doesn't know how much memory LLVM is
	allocating, so we may be allocating vast amounts of LLVM memory converting
	gimple into LLVM IR, but nonetheless the garbage collector won't free up GCC
	memory for us, even though there might be lots of memory to free. Work out
	some way of teaching the garbage collector about the amount of memory allocated
	by LLVM.

	After recent changes to the lto tree, it looks like functions are no longer
	being garbage collected after they are codegened. Investigate.


	Optimizations
	-------------

	After outputting global variables, maybe they can be deleted or marked somehow
	(eg: TREE_ASM_WRITTEN) so that GCC does not output them (such output gets sent
	to /dev/null, but it would be more efficient to teach GCC to not produce any in
	the first place). Investigate.

	Consider having DECL_LLVM and friends store values for trees local to a
	function in a separate map that can be cleared once the function has been
	emitted. Determining which trees are local (LABEL_DECL, VAR_DECL but not
	static etc) should be pretty quick, so the cost of routing to the right map
	should be insignificant, while having a much smaller map for globals could
	be a win.

	Consider using separate caches for types and globals.