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 05:19:50 -0400 Message-ID: References: <20230809094655.793FC18A4654@snark.thyrsus.com> <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> <87cyze6pb4.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="10151"; 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 11:20:35 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 1qZSzb-0002Rb-7h for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Aug 2023 11:20:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZSyu-00023G-Sz; Fri, 25 Aug 2023 05:19:52 -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 1qZSyt-000237-7k for emacs-devel@gnu.org; Fri, 25 Aug 2023 05:19:51 -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 1qZSys-0000sy-J4; Fri, 25 Aug 2023 05:19:50 -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=8zwTVm1eh1/SKeT4GO3+91Ca21ZAdb1awGz/xQgY2UQ=; b=ituttQSF3cS/jpjZ2WMr ajdKiUtosHmv+tXruvtB79L7tfWJShRJJVnA/DnEI1a6OH9vfbwHD7Reygtr6tfrSF2dI6wI3ZtUH CfXmJ3gFuEglThgVMu1dpkov4DIoI8MK2xW50x7coPCEuKPFX8s8dqxxdlpk9D6pISLvGH8esIgZL IT8AkZ401cIe0nt58/gfZnPNfj2NYUKQa9Zq5inU6MJOvzMKXDz6lHtxorgHah4dYZE56EIBdxjaP 6UXIRHSJUBoEN8xrgDHBNbUNhSmDt6OoRZGGRiNFpGwDGZ/My3aEQgonKP0HK284Qal9m5oNQnCJq fBsVBDN8OrRtnQ==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qZSys-0000dS-7A; Fri, 25 Aug 2023 05:19:50 -0400 In-Reply-To: <87cyze6pb4.fsf@localhost> (Ihor Radchenko's message of "Wed, 23 Aug 2023 10:11:43 +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:309207 Archived-At: Ihor Radchenko writes: > Andrea Corallo writes: > >> Yes the native compiler does value-type inference already (this is how >> the return type of functions is computed as well). > > Thanks for the confirmation! > > Do I understand correctly that value-type inference is still extremely > limited? Why? > I am confused about native compilation results for > > (defun test1 () > (let ((x (list 'a 'b 'c))) > (when (listp x) "Return value"))) > > (see ) Yes the native compiler is failing to optimize that, one reason is probably that list is not a pure function. This works better for example with: (defun test2 () (let ((x '(a b c))) (when (listp x) "Return value"))) But anyway it should work, trouble is that we call listp on something we know is a cons (set #(mvar 12095070 1 boolean) (call listp #(mvar 12094834 1 cons))) But the result is just a boolean instead of being a t. If we could have a bug report for this I can work on it as soon as I get time. >> 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 :( > > 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. >> 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. > > 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? > I tried > > (defun test1 () > (let ((x (list 'a 'b 'c))) > (when (listp x) "Return value"))) > (setq native-comp-debug 3) > (setq native-comp-verbose 3) > (native-compile #'test1 "/tmp/test1.eln") > > but it is not very clear what exactly is going on there. 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. Best Regards Andrea