Screaming-Fist: a JIT framework for Guile

Screaming-Fist: a JIT framework for Guile

[Nala Ginrut]

Hi Folks!
I'd like to introduce our new project named screaming-fist which is a JIT
framework based on libgccjit.

The project is still preliminary, but the POC could run.

The basic idea is to hide the JIT details and let users write Scheme-like
code for JIT on the fly.

here's the simple code:
--------------------------------
(import (screaming-fist jit))

(jit-define (square x)
  (:anno: (int) -> int)
  (* x x))
(square 5)

;; ==> 25
----------------------------------

And you can dump IR, say, gimple:
----------------------------------------------

(import (screaming-fist utils) (screaming-fist jit))
(parameterize ((dump-mode "gimple"))
 (jit-define (square x)
  (:anno: (int) -> int)
  (* x x)))

-------------------------------


The possible output could be:

------------------------------

int square (int x){
  int D.79;

  <D.76>:
  D.79 = x * x;
  return D.79;}

--------------------------------------------

The branching and looping codegen is still under debugging.

Here's the project page:

https://gitlab.com/SymeCloud/screaming-fist

Happy hacking!

Re: Screaming-Fist: a JIT framework for Guile

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]


Nala Ginrut <nalaginrut@gmail.com> writes:
> Hi Folks!
> I'd like to introduce our new project named screaming-fist which is a JIT
> framework based on libgccjit.
> (import (screaming-fist jit))
>
> (jit-define (square x)
>   (:anno: (int) -> int)
>   (* x x))
> (square 5)

That looks interesting!

Do you already have performance data?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Screaming-Fist: a JIT framework for Guile

[Nala Ginrut]

hi Arne!
Not yet, I'm still working on it before any convincing complex code for
performance evaluation.

The idea is to provide a Scheme like functional IR to make JIT easier to
use. However, the libgccjit IR is imperative based on assignments and
statements. So there are more works to do other than a traditional binding.


Best regards.

On Mon, Dec 4, 2023 at 4:49 AM Dr. Arne Babenhauserheide <arne_bab@web.de>
wrote:

>
> Nala Ginrut <nalaginrut@gmail.com> writes:
> > Hi Folks!
> > I'd like to introduce our new project named screaming-fist which is a JIT
> > framework based on libgccjit.
> > (import (screaming-fist jit))
> >
> > (jit-define (square x)
> >   (:anno: (int) -> int)
> >   (* x x))
> > (square 5)
>
> That looks interesting!
>
> Do you already have performance data?
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

Re: Screaming-Fist: a JIT framework for Guile

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1135 bytes --]



Op 03-12-2023 om 18:26 schreef Nala Ginrut:
> (jit-define (square x)
>    (:anno: (int) -> int)
>    (* x x))
> (square 5)


Potentially-overflowing arithmetic involving ints (not unsigned ints, 
but ints)? Best document somewhere to what the jit code '(* x x)' 
evaluates when (not (<= min-int (* x x) max-int))).

Personally, I'm in favor of explicit long names like

*/error-on-overflow     (<-- maybe on the C-level the function could 
return a tagged union representing (failure [no value]) / (success [some 
value], at a slight performance cost)
*/wrap-around
*/undefined-on-overflow (<-- like in C, for maximal performance and 
dragons).

(Likewise for +, - and unsigned int)

Sure, they are a bit verbose, but they are explicit and 
non-explicitness+undefined behaviour of'*' in C has caused serious 
issues in the past, so I'd think it's better that the programmer has to 
choose what, in their situation, are the appropriate semantics.

If/when someone desired shorter names, there could be a
(jit-define-alias * */wrap-around) or something like that for that?

Best regards,
Maxime Devos

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Screaming-Fist: a JIT framework for Guile

[Nala Ginrut]

Hi Maxime!



On Tue, Dec 5, 2023, 05:26 Maxime Devos <maximedevos@telenet.be> wrote:

>
>
> Op 03-12-2023 om 18:26 schreef Nala Ginrut:
> > (jit-define (square x)
> >    (:anno: (int) -> int)
> >    (* x x))
> > (square 5)
>
>
> Potentially-overflowing arithmetic involving ints (not unsigned ints,
> but ints)? Best document somewhere to what the jit code '(* x x)'
> evaluates when (not (<= min-int (* x x) max-int))).
>

There's no type inference in libgccjit, so the high level framework has to
handle accurate types.

I use "int" here because libgccjit only provides int rvalue constructor,
yet. It seems lack of rich number types as rvalue in the present
implementation. Even boolean has to be handled by high level framework and
cast it to int respectively.

May be we need GCC folks help.


> Personally, I'm in favor of explicit long names like
>
> */error-on-overflow     (<-- maybe on the C-level the function could
> return a tagged union representing (failure [no value]) / (success [some
> value], at a slight performance cost)
> */wrap-around
> */undefined-on-overflow (<-- like in C, for maximal performance and
> dragons).
>

There was such check, but I've removed it. Since even you detect the
int/short/long exactly, libgccjit only provides int rvalue for all cases of
numbers. I'm not sure if it's waiting for contribution or intended as an
unified int abstract.


> (Likewise for +, - and unsigned int)
>
> Sure, they are a bit verbose, but they are explicit and
> non-explicitness+undefined behaviour of'*' in C has caused serious
> issues in the past, so I'd think it's better that the programmer has to
> choose what, in their situation, are the appropriate semantics.
>

I see your point :-)
Yes, it's a bit hard to provide an abstract arithmetic with type inference
for all cases, providing each for different types will be easier and
flexible.

Thanks!
Best regards.


>

Re: Screaming-Fist: a JIT framework for Guile

[Nala Ginrut]

Hi folks, I confirmed that gcc_jit_context_new_rvalue_from_int is an
abstract for various numbers.

So the number's validation would be added then.

Best regards.

On Tue, Dec 5, 2023, 18:14 Nala Ginrut <nalaginrut@gmail.com> wrote:

> Hi Maxime!
>
>
>
> On Tue, Dec 5, 2023, 05:26 Maxime Devos <maximedevos@telenet.be> wrote:
>
>>
>>
>> Op 03-12-2023 om 18:26 schreef Nala Ginrut:
>> > (jit-define (square x)
>> >    (:anno: (int) -> int)
>> >    (* x x))
>> > (square 5)
>>
>>
>> Potentially-overflowing arithmetic involving ints (not unsigned ints,
>> but ints)? Best document somewhere to what the jit code '(* x x)'
>> evaluates when (not (<= min-int (* x x) max-int))).
>>
>
> There's no type inference in libgccjit, so the high level framework has to
> handle accurate types.
>
> I use "int" here because libgccjit only provides int rvalue constructor,
> yet. It seems lack of rich number types as rvalue in the present
> implementation. Even boolean has to be handled by high level framework and
> cast it to int respectively.
>
> May be we need GCC folks help.
>
>
>> Personally, I'm in favor of explicit long names like
>>
>> */error-on-overflow     (<-- maybe on the C-level the function could
>> return a tagged union representing (failure [no value]) / (success [some
>> value], at a slight performance cost)
>> */wrap-around
>> */undefined-on-overflow (<-- like in C, for maximal performance and
>> dragons).
>>
>
> There was such check, but I've removed it. Since even you detect the
> int/short/long exactly, libgccjit only provides int rvalue for all cases of
> numbers. I'm not sure if it's waiting for contribution or intended as an
> unified int abstract.
>
>
>> (Likewise for +, - and unsigned int)
>>
>> Sure, they are a bit verbose, but they are explicit and
>> non-explicitness+undefined behaviour of'*' in C has caused serious
>> issues in the past, so I'd think it's better that the programmer has to
>> choose what, in their situation, are the appropriate semantics.
>>
>
> I see your point :-)
> Yes, it's a bit hard to provide an abstract arithmetic with type inference
> for all cases, providing each for different types will be easier and
> flexible.
>
> Thanks!
> Best regards.
>
>
>>