unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: 64646-done@debbugs.gnu.org
Subject: bug#64646: Master: Native compiler doesn't always compile lambda forms.
Date: Thu, 09 Nov 2023 05:08:59 -0500	[thread overview]
Message-ID: <yp17cmr8chw.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <ZUv2vob6DGw7ladQ@ACM> (Alan Mackenzie's message of "Wed, 8 Nov 2023 20:59:42 +0000")

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Thu, Nov 02, 2023 at 13:32:21 -0400, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > This bug doesn't seem to be moving, so ....
>
>> > On Wed, Jul 26, 2023 at 10:57:01 -0400, Andrea Corallo wrote:
>> >> Alan Mackenzie <acm@muc.de> writes:
>
>> >> >> I'm not 100% convinced this behaviour is a bug tho.
>
>> >> > I don't understand that.  Why might it be incorrect to compile that inner
>> >> > lambda natively?
>
>> >> Hi Alan,
>
>> >> I'm not saying it would be incorrect.  I'm suggesting that if is not
>> >> specified what's the expected behaviour of compiling by name the outer
>> >> lambda it might not be a bug.
>
>> >> When we compile a whole compilation unit we indeed have to compile all
>> >> functions, in this case what we promised is I think not defined.
>
>> > I still don't understand that.  The doc string for native-compile says:
>
>> >     Compile FUNCTION-OR-FILE into native code.
>
>> > ..  I can't see any reason not also to compile inner lambda functions
>> > natively.
>
>> > Anyhow, to fix this bug (if such it be) is easy:
>
>> > diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
>> > index 181e5ca96a1..2360fbaa494 100644
>> > --- a/lisp/emacs-lisp/comp.el
>> > +++ b/lisp/emacs-lisp/comp.el
>> > @@ -1359,7 +1359,12 @@ comp-add-func-to-ctxt
>> >                (comp-ctxt-top-level-forms comp-ctxt)
>> >                (list (make-byte-to-native-func-def :name function-name
>> >                                                    :c-name c-name)))
>> > -        (comp-add-func-to-ctxt func))))
>> > +        (comp-add-func-to-ctxt func))
>> > +      ;; Handle any lambda functions in BYTE-CODE.
>> > +      (maphash (lambda (key val)
>> > +                 (unless (eq key (aref byte-code 1))
>> > +                   (comp-intern-func-in-ctxt key val)))
>> > +               byte-to-native-lambdas-h)))
>
>> >  (cl-defmethod comp-spill-lap-function ((form list))
>> >    "Byte-compile FORM, spilling data from the byte compiler."
>
>
>> > What do you say?
>
>> LGTM as long as indeed it does not regress any test. Speaking of which
>> with the patch I guess we want a test to cover this.
>
> Thanks.  I've committed a patch for this, including two extra tests which
> test that a nested lambda function also gets native compiled.
>
> I'm closing the bug with this post.
>
>> > Incidentally, the code in the various comp-spill-lap-function methods
>> > together with comp-intern-func-in-ctxt appears to have some code
>> > duplication.  Would it be possible to have the symbol and list methods of
>> > comp-spill-lap-function simply call comp-intern-func-in-ctxt the way the
>> > string method does?  That would simplify those two methods quite a bit.
>
>> Mmmh maybe, I think one has to try to see if the result is satisfactory.
>
> I've done this refactoring too.  The symbol and list methods for
> comp-spill-lap-function now have 17 and 15 lines respectively.  I hope
> you like it!

Look nice thanks!

  Andrea





      reply	other threads:[~2023-11-09 10:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 12:10 bug#64646: Master: Native compiler doesn't always compile lambda forms Alan Mackenzie
2023-07-15 13:06 ` Eli Zaretskii
2023-07-15 13:20   ` Alan Mackenzie
2023-07-16  4:16 ` Michael Heerdegen
2023-07-16  9:01   ` Alan Mackenzie
2023-07-17  2:01     ` Michael Heerdegen
2023-07-17 13:17 ` Andrea Corallo
2023-07-20 12:14   ` Alan Mackenzie
2023-07-26 14:57     ` Andrea Corallo
2023-10-29 13:21       ` Alan Mackenzie
2023-11-02 17:32         ` Andrea Corallo
2023-11-08 20:59           ` Alan Mackenzie
2023-11-09 10:08             ` Andrea Corallo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yp17cmr8chw.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=64646-done@debbugs.gnu.org \
    --cc=acm@muc.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).