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 18DB33858001 for ; Thu, 2 Sep 2021 17:10:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 18DB33858001 Received: by mail-yb1-xb36.google.com with SMTP id e131so5189518ybb.7 for ; Thu, 02 Sep 2021 10:10:06 -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=G50meODUxHbo9dkninMDDo9ukX55ETnkPMEs1U3czCk=; b=hrdLusBu25E260bCpjI5vkY8GCh3LCa6p6h4efOFB0qrXsM055Hh06bz8Kj8V0yzeI N9RUhn2TUfC/1YUaDwakULXme8sJYFZ6cvfob2YVHSbjd/rRhRLMd/sp0zUXk2tkLJyj aG9dOeHdHUlmLqp5RPr89yq7W81lgVtwt8PcTEqgwYZR00xcYUlLUMhVBNGJmO/VnAPz oNKIRsvALbXNZB0ql0pItKO3GLZOki8LN6dzmWbs6AXByujsSr75oGddRMr+HwxrPP+I +p3k73pRa5zncuBjgob4aCgYg1GpyDQe28o7sSTSimoU7BeHEO64mrw2yEol7jf0aWat 6LYA== X-Gm-Message-State: AOAM533cgbSffIDaOBgac8IBrZrneztjBDmtPOuPNQwceNls2LhKDxAp JXYkR0YIoRoAktAHubVdkUQCQEgh83RjejMuuAI= X-Google-Smtp-Source: ABdhPJyq6tv0S8STyD/BBVnukGLVYkbDDnaMcsyggfHhTQ2rGIHLDqffmmiBbP4tD/telB2dcLxXkQXnv8wPdLremKI= X-Received: by 2002:a25:2cd6:: with SMTP id s205mr5880737ybs.445.1630602605532; Thu, 02 Sep 2021 10:10:05 -0700 (PDT) MIME-Version: 1.0 References: <3ce0d8336fb7290d7a1dfcade0b2104dd3efcc77.camel@redhat.com> <22ba0b4c0ad695dcf6e8a59bf1b7a9a923fdbbd2.camel@redhat.com> In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Thu, 2 Sep 2021 19:09:49 +0200 Message-ID: Subject: Re: Sv: 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.9 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 17:10:07 -0000 Am Do., 2. Sept. 2021 um 19:06 Uhr schrieb Petter Tomner : > > I don't like the idea of "magic" variable names, since it can change th= e > meaning of existing client code. > > I was thinking of an API, maybe something like: > > Sorry, I thought it looked bad enough. I should have been clearer that it > was no serious patch and meant > for Marc Nieper-Wi=C3=9Fkirchen. I couldn't bother adding stuff all the c= all > chain up to test it. > Yes, thanks, that was a fine proof-of-concept. And looked bad enough for me. ;) The actual suggestion of "gcc_jit_global_set_register" looks good to me. Marc > > Is the name actually optional from the perspective of GCC's backend? > > Maybe allow NULL for the regname param if it is? > > No it seems to be no support for no name. I guess any solution would have > to poll for a register name first > and then set the asm name. > > Regards > > -----Ursprungligt meddelande----- > Fr=C3=A5n: David Malcolm > Skickat: den 2 september 2021 18:45 > Till: Petter Tomner ; Marc Nieper-Wi=C3=9Fkirchen < > marc.nieper+gnu@gmail.com>; jit@gcc.gnu.org > =C3=84mne: Re: Sv: Global register variables > > On Thu, 2021-09-02 at 16:05 +0000, Petter Tomner wrote: > > 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 > > I don't like the idea of "magic" variable names, since it can change the > meaning of existing client code. I was thinking of an API, maybe somethi= ng > like: > > extern gcc_jit_lvalue * > gcc_jit_global_set_register (gcc_jit_lvalue *global, > const char *regname); > > (taking inspiration from gcc_jit_global_set_initializer) ? > > > but there is an array "global_regs" in reginfo.c that is not reset > > after each run so only run it once. > > Good catch. Sounds like we'd need a reginfo_c_finalize, to be called fro= m > toplev::finalize in toplev.c > > > > 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. > > Is the name actually optional from the perspective of GCC's backend? > > Maybe allow NULL for the regname param if it is? > > Hope this is constructive > Dave > > > > > > > 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= Malcolm > > via Jit > > Skickat: den 2 september 2021 16:34 > > Till: Marc Nieper-Wi=C3=9Fkirchen ; > > jit@gcc.gnu.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 > > > > >