Sv: Sv: Global register variables

[Petter Tomner <tomner@kth.se>]

> 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 it was no serious patch and meant
for Marc Nieper-Wißkirchen. I couldn't bother adding stuff all the call chain up to test it.

> 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ån: David Malcolm <dmalcolm@redhat.com> 
Skickat: den 2 september 2021 18:45
Till: Petter Tomner <tomner@kth.se>; Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>; jit@gcc.gnu.org
Ämne: 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 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 <tomner@kth.se>
> 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 <pthread.h>
>  
>  #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 <jit-bounces+tomner=kth.se@gcc.gnu.org> För David Malcolm 
> via Jit
> Skickat: den 2 september 2021 16:34
> Till: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>;   
> 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
>