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.


>