From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 5EA483858039 for ; Thu, 2 Sep 2021 16:44:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5EA483858039 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-477-JBL5xFsSNCSZ6GNinFwnWg-1; Thu, 02 Sep 2021 12:44:50 -0400 X-MC-Unique: JBL5xFsSNCSZ6GNinFwnWg-1 Received: by mail-qt1-f199.google.com with SMTP id e6-20020ac84e46000000b0029baad9aaa0so2353322qtw.11 for ; Thu, 02 Sep 2021 09:44:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=+4C+0gtmo13W3ufS59p69nVoPVXovYQ8Bxg/R1xlXdw=; b=Hzh7T8lRIFoe+TjI6JViFp9+34w7xx2EHCwe1AcCkfqzGe8jCDcIdYehSdO/+TcrPR c5Ty0lQ1RkYSld80viO9P3qymOgfcZqWjPcIBhkxSl798+1ID8HKLmma8rydxr5aJWyB ZN/3FDg4HpmcWZSJD1zySJsYIbupQvDwdBQ784e+MbauE0m1teaEFLERx0shZTs4yu1+ 3i6B9xNt9VuUzQu/sWgqTEiQ5SMfo594++5ey7f0k+K+zkV0dubUNm0yIIAYOBmBhigs LOB2ix5VRMt5Q4gvOHCxMCxcOKRIb5iHRv21psNgGjBpgy2008+WgVNROODDRDJFPviP ByBg== X-Gm-Message-State: AOAM532iugF1Ad+7+BuctQvrwPFNt/bXpGsfOV6YNJA4EUJI/WUDti76 JxpZNKQkRS2Qfnaju03fvr2sdN6ja0etQcnNEvyvN9WPKG+Qn7hyZZT89QgbHJHjV4VPSaHr7dJ JkHCj+xg= X-Received: by 2002:ac8:794e:: with SMTP id r14mr3830386qtt.333.1630601089469; Thu, 02 Sep 2021 09:44:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyw9XK4/4AeIaV6nK9BIsociwVXk/7jrPyzI34IxEdEfCSIWTeqgs+d/EE2IANB7AHpQWyd7w== X-Received: by 2002:ac8:794e:: with SMTP id r14mr3830370qtt.333.1630601089197; Thu, 02 Sep 2021 09:44:49 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id t8sm1397077qtn.37.2021.09.02.09.44.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Sep 2021 09:44:48 -0700 (PDT) Message-ID: <22ba0b4c0ad695dcf6e8a59bf1b7a9a923fdbbd2.camel@redhat.com> Subject: Re: Sv: Global register variables From: David Malcolm To: Petter Tomner , Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= , "jit@gcc.gnu.org" Date: Thu, 02 Sep 2021 12:44:48 -0400 In-Reply-To: References: <3ce0d8336fb7290d7a1dfcade0b2104dd3efcc77.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 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:44:53 -0000 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 something 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 = "reg_"; > + > +    for (int i = 0; i < 4; i++) > +      if (name[i] != key[i]) goto bail; > +    if (!name[4]) goto bail; > + > +    DECL_REGISTER (inner) = 1; > +    set_user_assembler_name (inner, name + 4); > +    DECL_HARD_REGISTER (inner) = 1; > +  } > +bail: > + >    if (loc) >      set_tree_location (inner, loc); >   > -- > 2.20.1 > > -----Ursprungligt meddelande----- > Från: Jit För David Malcolm > via Jit > Skickat: den 2 september 2021 16:34 > Till: Marc Nieper-Wißkirchen ; > jit@gcc.gnu.org > Ämne: Re: Global register variables > > On Tue, 2021-08-31 at 08:39 +0200, Marc Nieper-Wißkirchen 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 >