[Top][All Lists]

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

Re: Ideal performance of ELisp

From: Lynn Winebarger
Subject: Re: Ideal performance of ELisp
Date: Wed, 17 Aug 2022 09:04:48 -0400

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
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


reply via email to

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