switches in GCC JIT?

[Basile Starynkevitch]

It would also be useful to have the indirect jump capability - LLVM
offers this and I used it in Ravi to help with performance (although
in the particular use case I did not really see much benefit).

> If so, it would probably need to be "struct gcc_jit_case", both for the
> sake of namespacing, and because "case" is a reserved word.
>
> That said, it would be the first non-opaque struct in the API, which
> makes me nervous; I guess we could make it opaque like this:
>
> extern gcc_jit_case *
> gcc_jit_context_new_case (gcc_jit_context *ctxt,
>    	                   gcc_jit_rvalue *min_value,
>                            gcc_jit_rvalue *max_value,
>                            gcc_jit_block *block);

Then probably gcc_jit_case would be an "object" and released with the 
context as are all others.
> though I don't know if that's better.
>
> I prefer the original API, fwiw (with 3 arrays), as it doesn't introduce
> a new type.

I'm ok with both, but the API with 3 arrays should IMHO also have a 
simpler function for non-range cases only.

> This isn't yet supported by libgccjit.  Maybe the API might look
> something like this:
>
> extern gcc_jit_rvalue *
> gcc_jit_block_get_address (gcc_jit_block *block);
>
> giving an rvalue of type void *, and:
>
> extern void
> gcc_jit_block_end_with_indirect_jump (gcc_jit_block *block,
>                                        gcc_jit_rvalue *expr);
>
> where "expr" must be of type void *, obtained via
> gcc_jit_block_get_address.
>
> That said, what use-cases are you thinking of?   The one I'm familiar
> with is threaded dispatch of the big switch statement typically seen in
> an interpreter, but presumably anyone using libgccjit is unrolling the
> switch statement into code.

Not always.

First, a possible use case for gccjit might be to compete with LLVM, 
that is to use gccjit (either as an ahead-of-time compiler component or 
as a JIT compiler component) as a framework for implementing any kind of 
compiler. Then you surely want most GCC and GIMPLE features to be 
available in GCCJIT.

(To be more precise, the OpenMP gimple codes are indeed not very useful 
in GCCJIT - or at least I believe they are not a priority; but the 
exception framework in Gimple, which today is not yet available in 
GCCJIT, might be useful to some)

Then, there are also realistic use cases for indirect jump inside a JIT. 
I would guess that an IPTABLE reimplementation which would JIT the 
iptables thing might want it. And every language which has an indirect 
jump would also profit from it.

Actually, my biased opinion on order of implementation of new features 
in GCCJIT is:

1. most important and most urgent: the switch & case support, without 
which many people (me included) won't use GCCJIT, because switch like 
statements are so common (and very useful) in a lot of languages
(and they are not the same as a sequence of if -else if...); BTW a naive 
implementation of some Javscript JIT infrastructure would also need it.

2. computed gotos & labels

3. exception support.

We should be able to handle the "dynamic Pascal" example of libjit on 
https://www.gnu.org/software/libjit/doc/libjit_3.html#Dynamic-Pascal as 
easily in gccjit as it is possible in libjit.


Is there any support for tailcails in GCCJIT? I guess that any call 
which GCC would optimize to a tailcall would also be a tailcal in GCCJIT....

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***