[Ecls-list] Megapatches ahead

[Matthew Mondor]

On Wed, 5 May 2010 17:48:14 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> The changes I am making are related to backporting some of the lowest layer
> of the new compiler (environment, declaration and proclamation manipulation,
> compilation drivers, externalizing compiler constants, compiler macros that
> optimize code, etc) so that both directories can share most of the code and
> I can make easier progress.

Very nice.

As I'm not very familiar with the compiler code, but have been wondering
lately after reading the arithmetic code:

Considering the code in c/num_arith.d all using cases on the cl_object
type, does this also mean that currently the compiler couldn't optimize
to use type-specific inline operations even if it made use of good
static type analysis?  Or can the compiler also generate inline code
which doesn't use these functions?

Also, would it only be worthwhile for a CL compiler to inline direct
arithmetic operators when the types are all fixnum, or is there
possibility to also do this with a few more types?

Finally, would it make sense to eventually add a few C inline functions
for operations on a few basic types like fixnum for use by the
compiler, considering the size of generic operation functions (which
are unlikely to get inlined by a C compiler using the inline word in
code or -O3 -finline-functions CFLAGS), for eventual use by the
compiler?  If so, for which type(s) would this make sense other than
fixnum?  And would using the C99 inline be acceptable for those smaller
functions?  If this is desirable I could volunteer to eventually
provide a diff for such functions...

I provide examples here to compare against the large ecl_plus()
function:

/*
 * The following examples are so small that they would likely get inlined,
 * and could be used when the compiler detects that both values are fixnum
 * (or are supposed to be, if we still need extra type safety):
 */

/* Ensuring type safety with failure */
inline cl_object
_ecl_fixnum_plus(cl_object x, cl_object y)
{

	switch (type_of(x)) {
	case t_fixnum:
		switch (type_of(y)) {
		case t_fixnum:
			return ecl_make_integer(fix(x) + fix(y));
		default:
			FEWrong_type_nth_arg(@[+], 2, y, @[number]);
		}
	default:
		FEWrong_type_nth_arg(@[+], 1, x, @[number]);
	}
}

/*
 * Ensuring type safety by calling the generic function as needed;
 * This would actually add overhead unless the compiler knows the objects
 * have a fair chance of being fixnum.
 */
inline cl_object
_ecl_fixnum_plus(cl_object x, cl_object y)
{

	if (type_of(x) == t_fixnum && type_of(y) == t_fixnum)
		return ecl_make_integer(fix(x) + fix(y));

	return ecl_plus(x, y);
}

/*
 * No type safety whatsoever (both objects are known to be fixnum reliably).
 * In this case it'd even be possible to directly inline the following code
 * or to use a macro for C89 compatibility, although the advantage of an
 * inline function would be the ability to compile with -fno-inline for
 * better debugging...
 */
inline cl_object
_ecl_fixnum_plus(cl_object x, cl_object y)
{

	return ecl_make_integer(fix(x) + fix(y));
}

#define _ECL_FIXNUM_PLUS(x, y)	ecl_make_integer(fix((x)) + fix((y)))

Thanks,
-- 
Matt