[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When should ralloc.c be used?

From: Daniel Colascione
Subject: Re: When should ralloc.c be used?
Date: Thu, 27 Oct 2016 16:32:36 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

"Perry E. Metzger" <address@hidden> writes:

> On Thu, 27 Oct 2016 14:07:46 -0700 Daniel Colascione
> <address@hidden> wrote:
>> If we need a compiler to make this happen, so be it. We'll just
>> require libgcc, or hell, check it in to the repository, the way gcc
>> checks in its dependencies.
>> An additional benefit of integrating with a compiler at runtime is
>> the potential to JIT elisp code. Both LLVM and GCC these days have
>> usable JIT interfaces. We could even serialize JIT traces in these
>> user Emacs dumps.
> Having a JIT for emacs bytecode (or some other IR) would be really
> superb. I had no idea that GCC now had JIT support, but if it is as
> easy to use as LLVM's, a prototype would not be a hard project. (I
> presume RMS would insist on GCC as the basis.)

GCC's interface isn't nearly as mature as LLVM's yet, but there's promise


> Of course, given that Emacs already byte compiles everything, maybe
> going straight to machine code rather than the bytecode + JIT would
> be good? Again, I don't know what GCC's infra is like, but if it is
> as good as LLVM's that would be quite straightforward.

AOT is all the rage right now (JEP 295), but I believe that tracing JITs
are ultimately the right choice for code density and installation
latency reasons. But this is one of those arguments that's never going
to be solved.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]