From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120685 invoked by alias); 24 Jun 2015 10:20:41 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 120652 invoked by uid 89); 24 Jun 2015 10:20:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: ovh.starynkevitch.net Message-ID: <558A846C.70003@starynkevitch.net> Date: Thu, 01 Jan 2015 00:00:00 -0000 From: Basile Starynkevitch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: David Malcolm , Dibyendu Majumdar CC: jit@gcc.gnu.org Subject: Re: switches in GCC JIT? References: <558880D7.7080503@starynkevitch.net> <1435009326.13727.16.camel@surprise> <558885E4.20706@starynkevitch.net> <1435019126.13727.21.camel@surprise> <1435106449.13727.35.camel@surprise> In-Reply-To: <1435106449.13727.35.camel@surprise> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-q2/txt/msg00103.txt.bz2 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: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***