From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Add more supported primitives in libgccjit IR (was: Shrinking the C core) Date: Mon, 21 Aug 2023 07:02:27 -0400 Message-ID: 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> <87v8d8fzr9.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14073"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, luangruo@yahoo.com, akrl@sdf.org, eliz@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 13:03: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 1qY2ge-0003Qi-LI for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 13:03:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY2g5-000388-UH; Mon, 21 Aug 2023 07:02:34 -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 1qY2g0-00036B-Tx for emacs-devel@gnu.org; Mon, 21 Aug 2023 07:02:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qY2g0-0007be-1t; Mon, 21 Aug 2023 07:02:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=9mlon9nEuV5HHkG+87/rNMcF2jobMAWMKVf/5fUAcxg=; b=D4/nO0zMVCBf 5z2d1ehzwvCoj0eYXOfRMj/9jzLhQmguaD0VW7vt8wNnCz89cAP0jPigqUaWQU5CnN/MKv7bJCdzz 5tkhBoB/3K4lDpgGh/lIJx7e7Q9awQHBKLAryXa9TA/4tBqmcUICBxuk1M6z21KRnDLblq0aAJ0E2 5bfFCSjAKy9Ry/yZOSLmOJglPm+McPwQrW0Nb5y6lvjTJJOWvZ8odxqRbpeYxEFibwrRCdfnbH+ch 9kGS81AIQ5WERo4FYkUk2/r5SN+fpTbuUXwkHaMDNe7iALJRcjCq8YWBQo8Pv5QoapXoajtd/fmUf aYXeqG8bOX5rPr/RSr/6wQ==; Original-Received: from ams by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qY2fz-0000sT-CC; Mon, 21 Aug 2023 07:02:27 -0400 In-Reply-To: <87v8d8fzr9.fsf@localhost> (message from Ihor Radchenko on Mon, 21 Aug 2023 10:36:42 +0000) 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:309051 Archived-At: > 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. It is absolutley correct, the Emacs compiler is not capable of doing what you are suggesting. There are no specific functions for fixnum comparison in Emacs Lisp, nor is the Emacs Lisp compiler capable of being instructed to do such specific things. I've been repeating this constantly now. That is needed to make programs faster in Lisp. The reason why SBCL is faster is because it allows individuals to instruct the compiler to do what is best for the program -- e.g., the org maintainers can write functions that are more specialized. Native compilation simply does not solve that!