From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Newsgroups: gmane.emacs.bugs Subject: bug#41615: [feature/native-comp] Dump prettier C code. Date: Sun, 31 May 2020 14:26:46 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="7940"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41615@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 31 19:28:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jfRko-0001zg-TB for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 May 2020 19:28:11 +0200 Original-Received: from localhost ([::1]:52286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfRkn-00083H-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 May 2020 13:28:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60862) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfRkg-00082u-8Y for bug-gnu-emacs@gnu.org; Sun, 31 May 2020 13:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50421) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jfRkf-00029X-WC for bug-gnu-emacs@gnu.org; Sun, 31 May 2020 13:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jfRkf-0002jV-TM for bug-gnu-emacs@gnu.org; Sun, 31 May 2020 13:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 May 2020 17:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41615 X-GNU-PR-Package: emacs Original-Received: via spool by 41615-submit@debbugs.gnu.org id=B41615.159094603810455 (code B ref 41615); Sun, 31 May 2020 17:28:01 +0000 Original-Received: (at 41615) by debbugs.gnu.org; 31 May 2020 17:27:18 +0000 Original-Received: from localhost ([127.0.0.1]:33734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfRjp-0002iR-Ah for submit@debbugs.gnu.org; Sun, 31 May 2020 13:27:18 -0400 Original-Received: from mail-ot1-f48.google.com ([209.85.210.48]:37403) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfRjk-0002ho-M3 for 41615@debbugs.gnu.org; Sun, 31 May 2020 13:27:07 -0400 Original-Received: by mail-ot1-f48.google.com with SMTP id x22so6119174otq.4 for <41615@debbugs.gnu.org>; Sun, 31 May 2020 10:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xQb/Q78ZsvSTSEFux1cmZLhxS+SOxftQ2/TNgf74GC0=; b=kqOqjOlcKAuSPZ7YY1PP8ASOGat7PfnXg9BGBh9Vplt1wuRxEE4YReCTjni75OLme4 +tDZWgcrkW/qezWYNNIOphXbDTb+tXPryDaUdQZqvXY4qUSc8fxxAawX6WrJokk9ORJ4 X/EbAk5a/vTVx5ATm34C7hrAhJtYgte8/RK6p5swKrKL8FC1FRvQFi7DSQ/oad9MZEN5 FFq6kSyQIl8SJji1RTgIWzbmXNxuS5JMVsiBjq+M1XrjWPVn1EE8tXD63nEl/egQ4A+p f7c9BKy10oE/vNWFiE4cbHzkV3yh+/q4b/PUmVqzBf1WSoiNlNdGH4tQO+b8/vJ1OFjM H3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xQb/Q78ZsvSTSEFux1cmZLhxS+SOxftQ2/TNgf74GC0=; b=YWieHgjj4GROzv1YjGiTTDEf55WuIyvDzdRfD6+r9CTas0fi9TX+duxpuopb/2vF9O 7B01GhYeCjbJBk87/WtGcYNeCNcEk9SAPR6bF0/9pq3aUYCcWGrYGgt/4EtCm21za3OH jMFka+CR6+VSFRl3cjMxPRGBTs9W3HWHkgC4+NH5mpdUT9xzWrEyox7O/iF8hrts33s5 hhuRqnUTY9lsidYI6qt4uMASI1TAeI3lpiQUMT2fozw6nfLeo/Iy0GnWPLcIFVYKXN5q jO3jCJKJ2zstQYLO7lR5vxtWYOpQruKIkP+z8vZkMZMWliLdSnc+9Q22ndUGGX81c2W9 ZzRw== X-Gm-Message-State: AOAM530830LqwvXs/xtZwGM25yrOl2qREw1GJ2ZNWvnFEPJw3SO422Op ks7t+4DGhYUqoN+XdOuaBzKbwkH9Ttwqe0V3+S0= X-Google-Smtp-Source: ABdhPJzx6OkYsCBac0wOf0ajKe8YgT7+KFEyH1tUpSQYw96t7/b60HxT+NGQkWR4TCiO9lsI48EDr3B7G6rxwMa3otY= X-Received: by 2002:a05:6830:2439:: with SMTP id k25mr13213716ots.352.1590946018970; Sun, 31 May 2020 10:26:58 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181303 Archived-At: > I believe bzero is unnecessary given these are static allocated. Ok with me. > For memcpy we can just use the standard library implementation given > elns are linked to it. The other advantage is that doing this way (here > at least) memcpy is not inlined also at speed 3, so we don't trap in the > optimizer issue! This is good! > All summed is even a little faster than the stock patch and closer to > the one with the specific GCC blob support. Good. > Let me know if you like the attached and if does the job for you too. I like it. I see calls to memcpy even with -O3, which is great. Nico El dom., 31 may. 2020 a las 13:57, Andrea Corallo () escribi= =C3=B3: > > Nicolas B=C3=A9rtolo writes: > > >> I like this considerably less :) > > > > Ok, let's say goodbye to this patch. > > > >> It introduces quite some complexity and the same advantage in > >> debuggability can be achieved with something like the attached 8 line > >> patch (untested). > > > > Sounds good, I haven't tested it either. > > > >> Generally speaking I want to try to keep our back-end as simple as we > >> manage to. > > > > I initially wrote this patch chasing the reason for slow compile times.= I think > > that a 10k line C file should be compiled much faster than what gccjit = achieves. > > I thought that "uncommon" (for C) ways of doing thing were causing gccj= it to get > > stuck trying to optimize them hard, until it gave up. I thought that fi= lling the > > static data using memcpy() and constant strings would help GCC recogniz= e this as > > a constant initialization and hopefully just store a completely initial= ized copy > > in memory. > > > > I found that GCC would inline memcpy() and the static initialization wo= uld turn > > into a very long unrolled loop with SSE instructions. I tested this wit= h -O3 > > only in gccjit to force maximum optimization. I found this super strang= e > > considering that -ftree-loop-distribute-patterns is enabled at -O3 and = it should > > recognize the naive_memcpy() function as an implementation of memcpy() = and issue > > calls to libc's implementation. Instead, it was inlining and unrolling = it. > > Ok you confirm the suspects I wrote in the other mail! > > I've used your patch as a base, apart for minors here and there I've > stripped out the definitions of bzero and memcpy. > > I believe bzero is unnecessary given these are static allocated. > > For memcpy we can just use the standard library implementation given > elns are linked to it. The other advantage is that doing this way (here > at least) memcpy is not inlined also at speed 3, so we don't trap in the > optimizer issue! > > All summed is even a little faster than the stock patch and closer to > the one with the specific GCC blob support. > > Let me know if you like the attached and if does the job for you too. > > Thanks > > Andrea > > -- > akrl@sdf.org