Re: Ideal performance of ELisp

[Lynn Winebarger]

On Tue, Aug 16, 2022 at 2:24 PM Andrea Corallo <akrl@sdf.org> wrote:
>
> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > On Tue, Aug 16, 2022 at 4:59 AM Andrea Corallo <akrl@sdf.org> wrote:
> >>
> >> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >>
> >
> > Ugh.  Why not inline LAP blocks?
>
> You could inline LAP or even LIMPLE relatively easily but I don't see
> any perf opportunity to take advantage from in doing that.

I suppose it depends on what type of instructions/machine model are
operated on by the respective IRs (there's no spec for Emacs LAP
code).  Assuming one of them allows you to operate directly on machine
values, without any implicit type-tagging/untagging, then you should
be able to do all the same kind of
abstraction-breaking-but-difficult-or-impossible-for-the-compiler-to-prove-safe
operations that C code could perform.  That is the point of the
proposed feature, isn't it?
Assuming LIMPLE is required, I'm not sure how the feature would be
incorporated for users without access to libgccjit.  Perhaps an
additional byte-code operator like "execute-limple-insn" could be
implemented that would support a set of supported "unsafe" LIMPLE
instructions?

Lynn