From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by sourceware.org (Postfix) with ESMTPS id 34EAD3858001 for ; Thu, 2 Sep 2021 16:34:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34EAD3858001 Received: by mail-yb1-xb36.google.com with SMTP id c6so4959459ybm.10 for ; Thu, 02 Sep 2021 09:34:03 -0700 (PDT) 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; bh=8N/nTV8ZjH1H/jkkU/TTYNtIEAeDWtcAyB3MmMkpMZM=; b=bzSwNSwTYTcYj+1ahppdnQzpwdTbsMDpVByoUaXDR4sHOvp/7tUarMLIGP9jW2P1MV 3lB1RqFrSG5W3D1drCH+qjlFAVWI1WOLZBLffCQ9nryzZLQTlcyIzU78l2JkEpoEhabU hKXl+30xkp3DQlmI8rgrclBj3e3d5xbw4+wlLcwdcRlQwHhljmwSTGTzmoZJaG3pXmKG AzghbJwdhbeK7tbWPs/NoluC1vEtMQNxGuKueG5DroWa91S50QQjGF0qmfB7zk7vqkPK LyoWxaqZvdMSVT1yVR0cPt7pg1AHYmT0GZWd5D/VxVwJH7p0eGBaf/qjSur8RuziFhdF mjrw== X-Gm-Message-State: AOAM53103fUTn5eljJzO6Ww0JyN0ZRDyh+5hvGwX04K1qJAHxQl9/5qm UXMknzdlUuLX/ZOBuRMuSz5jGuFQkvLIrezo96Y= X-Google-Smtp-Source: ABdhPJwdWdmkkJyPORZW8wBExyznFhPuY+FTVJI5K2bTBV4+t2Pfj8DSd95QazXEACDm+AEHa+9qy6yRM5XRiv6Z0zU= X-Received: by 2002:a5b:803:: with SMTP id x3mr4938076ybp.145.1630600442794; Thu, 02 Sep 2021 09:34:02 -0700 (PDT) MIME-Version: 1.0 References: <3ce0d8336fb7290d7a1dfcade0b2104dd3efcc77.camel@redhat.com> In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Thu, 2 Sep 2021 18:33:50 +0200 Message-ID: Subject: Re: Global register variables To: Petter Tomner Cc: David Malcolm , =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= , "jit@gcc.gnu.org" X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, FREEMAIL_REPLY, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 16:34:07 -0000 Thank you very much for this proof of concept! Am Do., 2. Sept. 2021 um 18:05 Uhr schrieb Petter Tomner : > Hi! Conceptually is seems quite straight forward if you want to try it on > some code you have. > See the attached code that hack any identifier starting with reg_* to a > "global register" named *. > > It seems to work with e.g "reg_r14" and "reg_r15" on my machine with some > silly getter and > setter functions for those registers but there is an array "global_regs" > in reginfo.c that is not > reset after each run so only run it once. And as EXPORTED global type. > > I guess error handling and eg. having not to specify register explicitly > for portability > would be the interesting and little bit harder part. > I think specifying a register explicitly is not that bad. This is what would be done in C code as well. Depending on the target system, the consumer of the libgccjit API would choose such registers. I don't see a good way to have the registers chosen automatically. For example, on a target with a lot of registers, I may want to pin a lot; while on a target with only a few, I may want to pin just one for the most important global. Or would you see libgccjit to do such heuristics? Marc > Regards > > From f45d0e328b21b2a4b23021c099f1f3b0ad6e6002 Mon Sep 17 00:00:00 2001 > From: Petter Tomner > Date: Thu, 2 Sep 2021 17:23:24 +0200 > Subject: [PATCH] Hack reg_* identifiers to global register > > --- > gcc/jit/jit-playback.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c > index 79ac525e5df..fa011ed4c0c 100644 > --- a/gcc/jit/jit-playback.c > +++ b/gcc/jit/jit-playback.c > @@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see > #include "gcc.h" > #include "diagnostic.h" > #include "stmt.h" > - > +#include "varasm.h" > #include > > #include "jit-playback.h" > @@ -567,6 +567,19 @@ global_new_decl (location *loc, > break; > } > > + { /* Filescope register variables on identifiers reg_REGNUM */ > + const char *key =3D "reg_"; > + > + for (int i =3D 0; i < 4; i++) > + if (name[i] !=3D key[i]) goto bail; > + if (!name[4]) goto bail; > + > + DECL_REGISTER (inner) =3D 1; > + set_user_assembler_name (inner, name + 4); > + DECL_HARD_REGISTER (inner) =3D 1; > + } > +bail: > + > if (loc) > set_tree_location (inner, loc); > > -- > 2.20.1 > > -----Ursprungligt meddelande----- > Fr=C3=A5n: Jit F=C3=B6r David M= alcolm via > Jit > Skickat: den 2 september 2021 16:34 > Till: Marc Nieper-Wi=C3=9Fkirchen ; jit@gcc.gn= u.org > =C3=84mne: Re: Global register variables > > On Tue, 2021-08-31 at 08:39 +0200, Marc Nieper-Wi=C3=9Fkirchen via Jit > wrote: > > Does libgccjit support GCC's global register variables ([1])? > > Not currently. > > > > > If not, could we expect them to be included? > > > One major use case of > > libgccjit seems to be JIT compilation of some virtual machine bytecode > > and virtual machines usually need a number of global variables (like > > some virtual stack pointer or heap pointer, etc.). It makes a lot of > > sense to hold them in global (callee-saved) registers. > > Sounds like a useful feature; if someone wants to cook up a patch I can > review it. > > Dave > >