project.org

Plan

To Do

C back end could use AUTO_CONS and AUTO_STRING

(info “(elisp) Stack-allocated Objects”)

need to handle out-of-ssa for exception edges

turn elcomp–iterate-over-bbs into a macro to be more elisp-like.

add a declare form to fix the indentation

maybe add a dynamic-module-API back end

`car` should be `const`, ditto cdr, car-safe, cdr-safe,

aref, etc also, in cprop.el, it seems like a const function could be pre-evaluated when all arguments are constant; not just a pure function

we should be able to notice NILP(Fconsp) and turn it into

CONSP. This requires unboxing

make an elcomp-debug-output-mode, derived from special-mode,

where “g” re-runs the command; handy for debugging should store the sexp and the backend function

arguments need types set to :bottom

typeinf.el doesn’t handle keywordp specially, but should

make sure calls to a lambda work ok

C BE should make a static function the call should resolve to a call to the compiled function somehow -> ?

clean up the calls to declare-function

I think ideally they should not be needed

A “catch” with a non-constant tag will still require

special handling in the IR, e.g. when converting to SSA form this isn’t done now

There are various spots where the :func slot of a call

is handled improperly

We need a `lexical-catch’ of some kind

Could also mark various subrs as “cannot throw” as a special case

Except we have Vthrow_on_input …

Common Lisp uses block and return for lexical catch, so

we should do that

see the “emacs bugs” section below

We can merge blocks with different exception handlers

if one of them doesn’t have any throwing instructions likewise if we have fake-unwind-protect?

We can remove specbind/unbind if there aren’t intervening statements

probably unimportant optimization though?

Can specbind or unbind throw?

Remove “defuns” from compiler?

We don’t handle lambdas at all

Need to do closure-conversion

Probably need to handle “closure”

the C core would ideally need updates to handle native closures

but there is probably a way to work around this

Some special forms are still not handled

“Ordinary special forms”

(let ((result nil)) (mapatoms (lambda (sym) (when (special-form-p (symbol-function sym)) (push sym result)))) result)

(defconst defvar interactive)

(Note track-mouse turned into a macro)

save-current-buffer

save-restriction

save-excursion

can turn throw->catch into a goto

(catch CONST (… (throw CONST val))) => R = val; GOTO done

We do this already but can do better by handling unwind-protect as well

Passes

SCCP pass

GVN pass

Note that we can copy-propagate into a funcall or apply

For apply this is a bit like strength reduction

Can we always optimize mapc and mapcar with a lambda?

If we add a compiler macro can it expand back to ‘itself’?

We can optimize some regexps.

for example looking-at-p with a constant can be turned into ordinary code especially if the regexp is very simple this would be a win same with string-match-p

At least a simple form of TCO is easy

Look into a smarter form of closure conversion

Possibly sometimes we could optimize away closed-over variables, etc

We could convert `elt’ to aref or nth if we deduced the type

This could just be done with a compiler macro. Or by rewriting ‘elt’ entirely into a macro

We could perhaps inline nth and nthcdr if the argument is a constant

Back Ends

Disassembly

C Code

if we’re generating code to compile and dlopen then we don’t really

need DEFUN, and generating a doc comment is the wrong thing to do

Currently does not handle QUIT etc.

Could use Aurélien’s “FFI” / DSO thing

Type inference would be great here, could do unboxing

this works ok but needs better code generation

Bytecode

bytecode from this compiler would probably be worse than what

emacs generates

however, we could instead write a new bytecode interpreter

a register-based interpreter would likely be faster anyway

Emacs Bugs and Changes

the emacs core needs to support a SUBR in a `closure’ list

we need the number of arguments constant exported

see eltoc.el if we write some kind of jit back end, we’ll need many more constants, like how to unbox

we need hacks to emacs for unwinding, see eltoc.el

in the c code we can get a vector of args

but elisp is always going to want a list for &rest we could do better with &vector-rest

There’s no way to recapture the fact that some CL ‘throw’ constructs

are lexical we need our own special hack. like maybe CL could put a special property on the magic symbols it makes

concat and mapconcat don’t allow characters

this seems unfriendly and pointless

vc-dir “i” gives an unhelpful error if any other file is marked

this seems somewhat useless

it seems strange for elisp to have both defstruct and defclass

given that it isn’t really planning to be CL

it seems that cl-nreconc would be more efficient as

(prog1 (nreverse x) (setcdr x y)) … not if x=nil?

I wonder if progv is implemented correctly now that

macroexpand is done eagerly