From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id 634DC3858414 for ; Tue, 7 Dec 2021 09:07:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 634DC3858414 Received: by mail-yb1-xb33.google.com with SMTP id d10so39136468ybe.3 for ; Tue, 07 Dec 2021 01:07:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AM9nSVsaGNrt4PcHwDRO0Xy/nBNChRQVzpfthswQP7w=; b=LFZmRrNAwowGxt63cNOTc8YXMq4qlHW9aF1aUiWzF8Oq9lCwTc+pjBFWQVuotUCe1V WrT77oKwPcfW385lOXaFq0eC1RWJMcuFZkO3RUeg14T+IRGI52puQg+kMD6/8PLyq6Nh p9jTP7WUtlydkyfSyGC+TcaRWnB2oDdGLmxLeQIKunp1mAElmvYDyDTN3fYh2sF5NDZ9 iAH9iwrOW43FiH4R04FapHenjY7bkW3GD5We5QbGzsZRBsDl6Oym2Mg6PsrltKlv4DV6 MCZ9PVJs7WDG6cKxvOlwEJHJyKT4vSE0jUj45M+0cwparXQACpnPM8OQCv0bmLPlWuxi dWXQ== X-Gm-Message-State: AOAM532b/85fp0HeihSM6svBTWqNVTOxybvav8F3DkKWBOt+FpYCP5xp dFLPpL8iRRDkgo7HMK2T5E2Tov+wXSnx+Lrox1U= X-Google-Smtp-Source: ABdhPJyM/2tsG3QuEOz+Dp5SalJla44s8gOgHHNtztit6WzMjeo4fJ3TMDk0+GPzml7gMy7WZ/0wRaeb9fTHkZggjKw= X-Received: by 2002:a25:dad4:: with SMTP id n203mr46812485ybf.554.1638868044333; Tue, 07 Dec 2021 01:07:24 -0800 (PST) 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: Tue, 7 Dec 2021 10:07:13 +0100 Message-ID: Subject: Re: Sv: Global register variables To: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Cc: Petter Tomner , David Malcolm , "jit@gcc.gnu.org" X-Spam-Status: No, score=-6.7 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: Tue, 07 Dec 2021 09:07:28 -0000 I have been thinking about this a bit more. An alternative approach, which has the advantage that no specific knowledge about registers on each supported architecture would be needed, would be to introduce a general new calling convention using fewer (or none) callee-save registers and more registers for arguments. What would have been "globals variables stored in registers" before, would now be extra arguments to functions and the new calling convention would make sure that these arguments are passed along the calling chain in registers. To make this work, one would need two things, I guess: (1) Define a new function attribute "regcall", say, for the GCC targets to be supported. (2) Add two new procedures to libgccjit: void gcc_jit_function_add_attribute (gcc_jit_function *func, const char* attr) void gcc_jit_function_type_add_attribute (gcc_jit_function_type, const char* attr) Implementing the latter is, of course, also of interest without (1) to support existing function attributes like "noreturn", for example. Are there any obstacles to implementing (2) in libgccjit? Thanks, Marc Am Do., 2. Sept. 2021 um 19:09 Uhr schrieb Marc Nieper-Wi=C3=9Fkirchen < marc.nieper+gnu@gmail.com>: > 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 >> the 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 i= t >> was no serious patch and meant >> for Marc Nieper-Wi=C3=9Fkirchen. I couldn't bother adding stuff all the = call >> 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 hav= e >> 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 someth= ing >> 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 >> from 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 Davi= d 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 >> > >> >> >>