emacs-devel
[Top][All Lists]
Advanced

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

Re: Correct byte compiler error/warning positions. The solution!


From: Alan Mackenzie
Subject: Re: Correct byte compiler error/warning positions. The solution!
Date: Thu, 2 Dec 2021 20:35:50 +0000

Hello, Andrea.

On Thu, Dec 02, 2021 at 16:31:55 +0000, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> Hi Alan,

> > On Wed, Dec 01, 2021 at 17:53:03 +0000, Andrea Corallo wrote:
> >> Eli Zaretskii <eliz@gnu.org> writes:

> >> [...]

> >> > If all the benchmarks show a slowdown <= 1%, I'm okay with merging it.

> >> > Thanks.

> >> Another quick note, I think we should evaluate the impact not only with
> >> different benchmarks but also using a native compiled build (ATM the
> >> branch has no support for that).

> > The change to the scratch/correct-warning-pos branch to work with native
> > compilation is probably quite small,

> Not so sure about that

:-)

> > but I don't know the native code
> > compiler (comp.el, etc.) at all.

> > Would you help me with it, please.

> Sure

> > The mechanism of the change was introducing @dfn{symbols with position}.
> > These are embodied in src/lisp.h with a new type tag
> > PVEC_SYMBOL_WITH_POS, and the type struct Lisp_Symbol_With_Pos.

> > The most pertinent changes in the branch are likewise those in
> > src/lisp.h.  There, there's a new flag variable,
> > symbols_with_pos_enabled, which is tested in the macros lisp_h_EQ,
> > lisp_h_SYMBOLP, and in the inline function XSYMBOL.  There are new
> > "primitive" macros, lisp_h_BASE_EQ, lisp_h_BARE_SYMBOL_P, and the inline
> > function XBARE_SYMBOL.  There are a few other things too, like
> > lisp_h_SYMBOL_WITH_POS_P.

> > All these changes can be seen with a git diff between the branch head
> > and the branch point in the master branch.

> The modifications needed are all and only going into comp.c.

OK.

> The function you have to extend is 'emit_EQ'.  You'll see we have an
> emit_* function for each corresponding macro/inline function used, ex:
> 'emit_XLI', 'emit_XCONS' etc...

OK.

> You'll have to define all the new one needed in order to use them use
> them in the new 'emit_EQ'.

Thanks.  I'm currently going through the tutorial at
https://gcc.gnu.org/onlinedocs/jit/intro/tutorial....html, so it may be a
day or two before I start asking you questions.  ;-)

I can see already I'll need an emit_BASE_EQ (a renaming of the current
emit_EQ), and one or two others.

Hopefully, we'll get this up and running in a few days, or a week or two
at most.

> Best Regards

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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