dragonegg/TODO - llvm-archive - Git at Google

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

 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 the "target" tool.  This should be done
 from a configure script, rather from the Makefile.

 Define LLVM_TARGET_NAME from the Makefile rather than being specified in
 llvm-target.h.  Maybe LLVM_TARGET_INTRINSIC_PREFIX could go too.  An annoyance
 is that the target tool returns "x86" while what is needed is "X86".

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

 Consider using separate caches for types and globals.

 Correctness
 -----------

 GCC now has per-function optimization levels.  Add support for this.

 Fortran is currently broken because it has a boolean type with a precision
 of 1 bit but size not equal to 8 bits.  We convert to i1 which has the wrong
 AllocSize.  Fix this by distinguishing between the "memory type" used for
 passing the value around in memory (which would be i32 for this Fortran type),
 and the "register type" used for passing about in register (i1 in this case).
 This should tie in nicely with gimple registers versus references.

 Unify the code that determines which LLVM linkage type to use.  Need to do
 a bunch of experimenting to work out how the mapping should really be done.

 Code quality
 ------------

 Check the effect on code speed of having complex numbers be first class
 structures, i.e. values rather than in-memory aggregates.

 Clarify and extend the distinction between gimple registers and "the rest",
 the rest being mostly references.

 BIT_FIELD_REF is used to extract (and presumably insert) vector elements.
 Consider turning this directly into the corresponding vector operations.

 Work in terms of units rather than octets (i8).  For example, if the target
 has a 16 bit byte, then use i16 for byte addressing.

 Features
 --------

 Output proper debug info rather than throwing most of it away.

 Add support for exception handling.

 Many x86 specific builtins are not supported, even though it would be easy to
 add support for some of them, for example the 256 bit versions of builtins we
 do support.  Improve this.

 The GCC builtin lowering outputs helpful warnings (for example,
 20081109_0.c:3:35: warning: attempt to free a non-heap object ‘bar’,
 see maybe_emit_free_warning), but we don't.  Improve this somehow.
	Build system
	------------

	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 the "target" tool. This should be done
	from a configure script, rather from the Makefile.

	Define LLVM_TARGET_NAME from the Makefile rather than being specified in
	llvm-target.h. Maybe LLVM_TARGET_INTRINSIC_PREFIX could go too. An annoyance
	is that the target tool returns "x86" while what is needed is "X86".

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

	Consider using separate caches for types and globals.

	Correctness
	-----------

	GCC now has per-function optimization levels. Add support for this.

	Fortran is currently broken because it has a boolean type with a precision
	of 1 bit but size not equal to 8 bits. We convert to i1 which has the wrong
	AllocSize. Fix this by distinguishing between the "memory type" used for
	passing the value around in memory (which would be i32 for this Fortran type),
	and the "register type" used for passing about in register (i1 in this case).
	This should tie in nicely with gimple registers versus references.

	Unify the code that determines which LLVM linkage type to use. Need to do
	a bunch of experimenting to work out how the mapping should really be done.

	Code quality
	------------

	Check the effect on code speed of having complex numbers be first class
	structures, i.e. values rather than in-memory aggregates.

	Clarify and extend the distinction between gimple registers and "the rest",
	the rest being mostly references.

	BIT_FIELD_REF is used to extract (and presumably insert) vector elements.
	Consider turning this directly into the corresponding vector operations.

	Work in terms of units rather than octets (i8). For example, if the target
	has a 16 bit byte, then use i16 for byte addressing.

	Features
	--------

	Output proper debug info rather than throwing most of it away.

	Add support for exception handling.

	Many x86 specific builtins are not supported, even though it would be easy to
	add support for some of them, for example the 256 bit versions of builtins we
	do support. Improve this.

	The GCC builtin lowering outputs helpful warnings (for example,
	20081109_0.c:3:35: warning: attempt to free a non-heap object ‘bar’,
	see maybe_emit_free_warning), but we don't. Improve this somehow.