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 Date: Fri, 25 Aug 2023 11:06:56 +0000 Message-ID: <87il93bctr.fsf@localhost> 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="35057"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , ams@gnu.org, gregory@heytings.org, luangruo@yahoo.com, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 25 13:07:27 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 1qZUf1-0008sP-1e for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Aug 2023 13:07:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZUeH-0005yh-Sk; Fri, 25 Aug 2023 07:06:41 -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 1qZUeE-0005vv-Ki for emacs-devel@gnu.org; Fri, 25 Aug 2023 07:06:39 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZUe8-0005na-89 for emacs-devel@gnu.org; Fri, 25 Aug 2023 07:06:36 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1B19C240105 for ; Fri, 25 Aug 2023 13:06:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692961587; bh=wKOoJIad60OXyZtUPW9GeN/BCaespmvd0uKbEf47Pkk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Z1i5AfDDO6JsTdNwG6AquFscnA2/UQ2UpE2CadAhSlirRFI6z4imGkojaHl0QpQfY IktHs8C/x/wZrjpLqhl6bSLfVEmE4B/ux1qa6bjfkq0a1xOouziVGkUUPOUm/IUeZU 1T/99yl+1/2v04WNllfrayqnKV6OMC8010Md1Sgwwl7GgJizmqQpCpKbV9e06yF/SJ xEx+/keoIJMOqq9MiFjEY/uNtcf+s1a75DrH8bkIy8it9W1STTAQpAYpdP6KgGv+eL xkUz/Ohh8TIyvRcO8MFSsEBG7NB7Ntp+nL2VB29wK9Q0J7RIc2ofP60RTIR2AevL3t TN7H7zNKgDhjg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RXHFZ14Vgz9rxB; Fri, 25 Aug 2023 13:06:26 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.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=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:309214 Archived-At: 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? > 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 >> 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. >> 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at