Re: switches in GCC JIT?

[Dibyendu Majumdar <mobile@majumdar.org.uk>]

On 24 June 2015 at 01:40, David Malcolm <dmalcolm@redhat.com> wrote:
>> The API looks ok to me but would it be more user friendly if you
>> created a struct to hold the case values and blocks together? That is:
>>
>> struct case {
>>   gcc_jit_rvalue *min_value;
>>   gcc_jit_rvalue *max_value;
>>   gcc_jit_block *block;
>> };
>>
>> Then the last three parameters could be replaced by 'struct case *'.
>
> Is is actually easier that way?
>
> 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.

Yes of course, my bad.

>
> 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);
>
> though I don't know if that's better.
>

Maybe in this case it doesn't need to be opaque as it is not a
libgccjit construct - in the sense that it is only there as a
convenience to pass parameters in.


> I prefer the original API, fwiw (with 3 arrays), as it doesn't introduce
> a new type.

Ok by me - I don't really know which one will be better in the long
run, it will only become apparent with use.

>
>> >> BTW, if we don't have switches, we should at least have indirect jumps,
>> >> and the ability to retrieve, as a label, the starting address of any
>> >> basic block. (i.e. the equivalent of goto *ptr; and of &&label in C). If
>> >> that is possible today, we need more documentation about that (at least
>> >> saying that switch statements could be translated that way)
>> >>
>>
>> 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).
>
> This isn't yet supported by libgccjit.
>
> 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.

Agree, that is one of the reasons for creating a JIT in the first
place - to get rid of the switch. I used indirect branches in the
numeric for loop construct. The problem here was that Lua allows the
loop index to be either integer or floating, and the step can be
negative or positive. The original Lua bytecode has branching logic to
deal with this, but at the start of the loop it is known what the
index looks like. So then when it comes to looping rather than
rechecking the type and direction, one can use an indirect branch
which was setup at the beginning of the loop.

I found that this improves things but not very much. In the end I also
implemented specialized bytecodes for integer index, and positive step
- as this is the most common use case. The optimizer deals much better
with this - and as you saw, can recognize the loop and eliminate it
altogether. Not so with the indirect branching version.

So right now I have no need of this for Ravi - hence not a priority
from my point of view.

BTW I also do not need exception handling for Ravi as Lua uses
longjmp/setjmp for this. But other languages (including Python) need
it I think.

Another thing that many implementations need is support for garbage
collection. Again for Ravi I am fortunate that because Lua uses its
own "stack" - and the runtime manages GC of objects on that stack, I
do not need to worry about it.

Regards
Dibyendu