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: Fri, 25 Aug 2023 10:26:20 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87cyze6pb4.fsf@localhost> <87il93bctr.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8663"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , ams@gnu.org, gregory@heytings.org, luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 25 16:27:28 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 1qZXmZ-00025P-TK for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Aug 2023 16:27:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZXlZ-0001Bm-Uq; Fri, 25 Aug 2023 10:26:25 -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 1qZXlY-0001BX-JD for emacs-devel@gnu.org; Fri, 25 Aug 2023 10:26:24 -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 1qZXlX-0005Ul-5S; Fri, 25 Aug 2023 10:26:23 -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=H3dNVdOSoe3ZO5tGr85aY1me5HfTmVztSaqb+Fg/US0=; b=dE8Bmng2ZN69n9MbvSNT aVEhGwqpF+LbNzuhhdQRDUdCWMVBkhuwhC2gKLYRr9n0YCnLl/WhHW9+abOWrdYsDrhUK25qrtTTG nxKvizh8ZZAvYrpC0NzFvsxOXtQIbRek0ig/CiG7Ss6N7022v1NJpLNtILF8SEbQMaeRqq8ieYAci zuJscxeakTj7KG34rbmKZRqkaPZdRt47XTRCn30bX9w6WFQB/3MM5SNyb9AaCIRnt7Fazg3QckUIK Nz9dZ2cy5rcqjXJlqT1ctQ7RUEaw8j4jPMMx04pcHHIjRGeSjNpGG2a9/gZ7A1tBGXNyvQqqYwXP9 7VPGTf9qr0ejbg==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qZXlV-00011f-HI; Fri, 25 Aug 2023 10:26:21 -0400 In-Reply-To: <87il93bctr.fsf@localhost> (Ihor Radchenko's message of "Fri, 25 Aug 2023 11:06:56 +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:309218 Archived-At: Ihor Radchenko writes: > Andrea Corallo writes: > >>> Do I understand correctly that value-type inference is still extremely >>> limited? >> >> Why? > > Because when I tried to check if there is type optimization, I ran into > that `lisp' + `listp' call that was not optimized. > > Are there other known instances of such missing inference? This field is largely unexplored, probably when people will start paying more attention to the inferred return type of lisp functions we will get more bug reports for missed opportunities. >> If we could have a bug report for this I can work on it as soon as I get >> time. > > Done. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65527 Thanks >>> Do you have any comment on the problem with having multiple parallel >>> implementations of the same subroutine? >> >> It's not nice but if justified by performance for few core functions I >> think is acceptable. > > I just thought if we could have this native compilation-specific > implementations done in Elisp instead of C. AFAIU, it would then be > inlined as needed just as a part of normal nativecomp optimizations. But > the main question if it could be possible to retain C performance in the > generic case when argument values cannot be inferred ahead of time. No, that is not reasonable, CMUCL code as SBCL one when not micro optimized are rather slow compared to C, still native compilation brings a good boost of performance in the execution engine. Fact is that often, the execution engine is not the perf bottle neck in our application, usual suspects are runtime functions and GC off-course. >>> Is there any detailed information about the format of native compile >>> debug output? >> >> Not so far sorry, that's an internal dump format, do you have any >> specific question? >> ... >> The compiler performs a series of transformations on the code, those are >> called "passes". In the *Native-compile-Log* you can see the dump of >> the code for each function being compiled in the current intermendiate >> rapresentation. You'll see that the first intermediate rapresentation >> is LAP, most of the following passes are dumped in LIMPLE. > > I have no questions about passes - they are described in your paper. > Though it would be nice to put a reference to it in log buffer, manual, > or even share the paper together with Emacs sources. > > However, the internal dump format prevents more detailed understanding. > For example, there is no easy way for other people to figure out what > goes wrong during the optimization passes without knowing the dump > format. Having an example annotated debug output would be helpful to > make things more clear. Well if it helps the most important LIMPLE operators are AFAIR documented in the paper you refer to. I don't think I've now time to write more doc on this, but it should pretty straight forward to compare the the output of the last LIMPLE with what we emit as libgccjitIR to understand what's the meaning to start digging into the subject. Best Regards Andrea