Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core)

[Ihor Radchenko <yantar92@posteo.net>]

Gregory Heytings <gregory@heytings.org> writes:

> I'm not sure elisp-benchmarks are representative enough of actual Elisp 
> code...

Any better ideas?

> Look at data.c:arith_driver.  You'll see that it's essentially a function 
> which dispatches the handling of its arguments depending on their type...
>
> These integer/float/bignum types are not known at compilation time ...

This is not correct. If you have something like
(progn (setq x 1) (> x 2)), compiler is actually able to determine the
type of X at compilation time.

Not to say that such insight is always possible, but it is a big part of
what native compilation does in Elisp. I strongly encourage you to read
through https://zenodo.org/record/3736363 - it describes what is being
done during native compilation.

---

Now, about my actual suggestion here:

Even if native compilation determines some variable types at compile
time, it cannot always make use of this information because it is has
knowledge about byte-compiled Elisp instructions, but not about what is
inside Elisp subr primitives. With a few exceptions described in "Section
3.8 final (code layout)" of the linked paper:

    This pass is also responsible for substituting the calls to
    selected primitive functions with an equivalent implementation
    described in libgccjit IR. This happens for small and frequently used
    functions such as: car, cdr, setcar, setcdr, 1+, 1-, or - (negation).

In the my previous message, I have identified a few more candidates to
implement in this libgccjit IR.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>