From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core) Date: Mon, 21 Aug 2023 10:36:42 +0000 Message-ID: <87v8d8fzr9.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <877cpp914t.fsf@localhost> <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> <87h6ot7cf3.fsf@localhost> <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org> <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com> <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com> <87pm3h56ig.fsf@localhost> <87edjxarhz.fsf@yahoo.com> <87edjw4uw4.fsf@localhost> <77daee02cf1ba0db70c1@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7776"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Andrea Corallo , Eli Zaretskii , ams@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 12:37:08 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qY2HT-0001n4-Oe for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 12:37:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY2Gh-0004K4-Nc; Mon, 21 Aug 2023 06:36:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY2Gg-0004Jp-Cx for emacs-devel@gnu.org; Mon, 21 Aug 2023 06:36:18 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY2Gd-0002Sp-Np for emacs-devel@gnu.org; Mon, 21 Aug 2023 06:36:18 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E595B240027 for ; Mon, 21 Aug 2023 12:36:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692614172; bh=g4GhrbktawgWGAfO1de1bAfIL/bWH0smnEEpjrYg0m4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=QDbygrmDcU7tj8SwWPDj6AjU++zDO+IGfKW2qVdy/7Z+RfIx/UhL1/TLCuLPDEp42 4y56IAV4uPH3tYjn0KjHolVTl/HL9vXK8a1IZVANBMAvIiSqCb6lMfXQk6YYcEGRXR jBoLE/i6uEqrVCJViSNDz7l+PUHZIgp4V8HqbWygOeSLEwZY13xoFQxGhFVrrOSIgX I7+BN4J+OoRHT8g0u1zG6mehfMbx9j2E81mXXEx82gJrH/lsfikcS7vnpMZbFCxk/Q PfobuNuvFzg5hC7jS7XDmJd+yFMzhavhaWXjYEYEgPZ6eEgS+ldxWM9otsytKj4Vew v/behZvmi3tkQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RTpmW62jJz6tvw; Mon, 21 Aug 2023 12:36:11 +0200 (CEST) In-Reply-To: <77daee02cf1ba0db70c1@heytings.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309046 Archived-At: Gregory Heytings 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 . Support Org development at , or support my work at