Re: Emacs Lisp JIT Compiler

[Eli Zaretskii]

> From: Tom Tromey <address@hidden>
> Cc: Tom Tromey <address@hidden>,  address@hidden
> Date: Fri, 24 Aug 2018 11:54:06 -0600
> 
> It looks pretty good to me.  I was surprised to see the code to
> dynamically load libjit, but I don't really know what restrictions the
> MinGW port is subject to.

In general, any library that is not strictly required for Emacs to
work (i.e. it either supports an optional feature or we have fallback
code to provide the same feature) should on Windows ideally be probed
at run time and loaded dynamically only if it's available, because we
want to allow users to run Emacs without those libraries being
installed.  The reason is that finding and installing all those
libraries is not always easy on Windows.

> There are several hunks like:
> 
> +#if EMACS_INT_MAX <= LONG_MAX
>        tem = jit_value_create_nint_constant (func, jit_type_sys_int,
>                                           MOST_POSITIVE_FIXNUM);
> +#else
> +      tem = jit_value_create_long_constant (func, jit_type_sys_longlong,
> +                                         MOST_POSITIVE_FIXNUM);
> +#endif
> 
> Here I think it would be better to define a new type at init time and
> avoid #ifs in the code itself.

Maybe I'm missing something, but I didn't see how to do that with just
a type definition.  jit_value_create_long_constant is special in that
it allows to create 64-bit constants in a 32-bit build, by allocating
a 64-bit buffer and storing it address in the jit_value_t object it
returns.  jit_value_get_long_constant is then capable to access the
value in that buffer.  By contrast, all the other jit_value_create_*
functions store the value directly in the jit_value_t object, so they
can support values that are no wider than the native intptr_t type.

> I like the introduction of lisp_object_type for this reason.  I think I
> was being a bit lax about the types here, as you note.  Most things,
> like the CONSTANT macro, I think should be using lisp_object_type,
> because that's the fundamental type of bytecode operations.  Only
> specialized spots like extracting a fixnum value or calling some C
> function should be using other types.

We could indeed use lisp_object_type more, but that won't save us from
using jit_value_create_long_constant, as long as we want to support
the --with-wide-int build.  And we cannot replace the calls to
jit_value_create_nint_constant with the long variant because that will
make the code less efficient in 32-bit builds without wide ints.

But I will take another look and see what can be done to have less
#ifdef's.