From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Add more supported primitives in libgccjit IR Date: Mon, 21 Aug 2023 10:49:06 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87jztofwqm.fsf@localhost> <83cyzgvb70.fsf@gnu.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="34195"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Ihor Radchenko , ams@gnu.org, gregory@heytings.org, luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 16:49:39 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 1qY6Dr-0008eU-9g for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 16:49:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qY6DP-0006AJ-69; Mon, 21 Aug 2023 10:49:11 -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 1qY6DN-0006A7-4p for emacs-devel@gnu.org; Mon, 21 Aug 2023 10:49:09 -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 1qY6DL-0000lB-VE; Mon, 21 Aug 2023 10:49:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=B59kJgbKMlLJbQgffpf4mdezplu5/oC0Lv0qTB+6n+M=; b=naVoH+FE+SFzjobcOpZa bMo8vCrpOb1gxzb0veS98rTqjhaDMfNQLSxrSgt2lhA4mBjhsonz+DOOTpoYq6PKavql9FpwaWJQJ QUPy24u/6t72FAK1rtQI5pjgKJk8drv17FKM5yiQPGZOGQLu6J8NoAx7s8KnTmnca4uGm2VhK5RZm Pp9nYcZNj98aijrs0YqAIhmh+RhnGLahlxNZE5vMrnwOsgtLpfI2ecUBz3mS4wW6XEfRGlemCJdXt oOwMJPUzccCvAUwdmynRL+Sw69gbbcY012IDtLM2I+d+LLlKvu+8h32RdVUU3YxN07Nzs5tkpWA2p OtE+H63OEdurkA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qY6DK-0007s0-QD; Mon, 21 Aug 2023 10:49:06 -0400 In-Reply-To: <83cyzgvb70.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Aug 2023 15:20:35 +0300") 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:309081 Archived-At: Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: gregory@heytings.org, luangruo@yahoo.com, akrl@sdf.org, eliz@gnu.org, >> incal@dataswamp.org, emacs-devel@gnu.org >> Date: Mon, 21 Aug 2023 11:41:53 +0000 >> >> "Alfred M. Szmidt" writes: >> >> > > 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. >> >> I can see >> >> /* >> Define a substitute for Fadd1 Fsub1. >> Currently expose just fixnum arithmetic. >> */ >> >> static void >> define_add1_sub1 (void) >> >> in comp.c >> >> So, there is some type-specific optimization going on. >> It looks very limited though. > > This discussion is almost useless without Andrea on board, and you are > using hist stale email address. Please use the one I used here > instead. > > And I really suggest that people wait for Andrea to chime in, before > discussing code that he wrote and still maintains very actively. Hello Eli & all, sorry for being late to the party, I'm on holiday :) Anyway to clarify: Yes the native compiler does value-type inference already (this is how the return type of functions is computed as well). Yes one can already type hint an object to the compiler, even if this is limited to cons and fixnums (making it generic is on my todo list). Yes would be great IMO to extend this mechanism to function arguments eventually as well (I might give it a go after summer?). Yes the backend tries to inline some code when possible (ex define_add1_sub1). Yes we could add more of this inlining, the infrastructure is already there but I personally had no time to work on this :( Yes would be great to work on this benchmark driven, even if this open the classic question of what is a set of rapresentative benchmarks. My next activity when my time is not used by maintenance and other activities of my life will be focused more on safetyness and correctness I think. I'd love to work 100% on Emacs but I must pay my bills like everyone :) If someone is interested on working on some of those points (or other areas of the native compiler) I'm happy to provided help as much as I can. I'm sorry to observe that this conversation was fueled by someone explaining mechanisms with no understanding of how our system works, this makes people just loose their time :/ Best Regards Andrea