From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6134 invoked by alias); 24 Oct 2013 18:20:55 -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 6109 invoked by uid 89); 24 Oct 2013 18:20:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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: mx1.redhat.com Message-ID: <1382638833.2675.82.camel@surprise> Subject: gcc_jit_context (was Re: Python API (was Re: Build errors)) From: David Malcolm To: Simon Feltman Cc: jit Date: Tue, 01 Jan 2013 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-SW-Source: 2013-q4/txt/msg00038.txt.bz2 On Thu, 2013-10-24 at 03:36 -0700, Simon Feltman wrote: > On Wed, Oct 23, 2013 at 10:20 PM, Simon Feltman wrote: > > ... This is well beyond my knowledge of compiler architecture, > > but it seems like this could be cleaner? > > > > the_type = ctxt.get_type(gccjit.Type.INT) > > local_i = fn.new_local(the_type, b"i") > > > > could be: > > local_i = fn.new_local(gccjit.Type.INT, b"i") > > Digging into this a bit more, it looks like the gccjit API is sort of > synthesizing the context dependence for types anyhow. e.g. gcc > internals already seem to be defining the type nodes as globals > (uint64_type_node). So perhaps the API is attempting to present a new > model which the implementation may morph into? Yes: as well as the JIT work, I'm also trying to modularize the core of GCC: in the future I want to support multiple contexts of GCC state within one process; there's now a "gcc::context" object in GCC proper, though currently it only has one field (the pass manager). [1] Hence I want the API to avoid a concept of "the" int type within the process, instead, merely a given context's int type. As you found out, that part is currently somewhat smoke-and-mirrors. BTW, internally most of the objects in the library already "know" which context they belong to, and it would be easy to add that to the rest, so it's not strictly necessary for many of the C entrypoints to be passed a context pointer. Some of the more recent entrypoints don't bother e.g.: gcc_jit_rvalue_dereference. So I've been thinking about reworking some of the existing C API to do this, eliminating the context ptr from them. So e.g. extern gcc_jit_rvalue * gcc_jit_context_new_rvalue_from_int (gcc_jit_context *ctxt, gcc_jit_type *type, int value); extern gcc_jit_rvalue * gcc_jit_context_zero (gcc_jit_context *ctxt, gcc_jit_type *type); might become: extern gcc_jit_rvalue * gcc_jit_type_rvalue_from_int (gcc_jit_type *type, int value); extern gcc_jit_rvalue * gcc_jit_type_zero (gcc_jit_type *type); That way you'd generally go from a context to make your types, globals and functions, and then you'd invoke methods on the types to make rvalues, and on the functions to add statements (with a few exceptions e.g. perhaps a rvalue *gcc_jit_function_make_call?) The above may be my Python background speaking (in that in Python there's such a strong relationship between types and making instances); I wonder how natural such an API sounds to others on the list? As another example, for binary ops; currently we have: extern gcc_jit_rvalue * gcc_jit_context_new_binary_op (gcc_jit_context *ctxt, gcc_jit_location *loc, enum gcc_jit_binary_op op, gcc_jit_type *result_type, gcc_jit_rvalue *a, gcc_jit_rvalue *b); which might become: extern gcc_jit_rvalue * gcc_jit_type_binary_op (gcc_jit_type *result_type, gcc_jit_location *loc, enum gcc_jit_binary_op op, gcc_jit_rvalue *a, gcc_jit_rvalue *b); which itself raises issues of casts, which I've been mostly ignoring for now. FWIW gcc_jit_function_add_assignment currently adds a type-coercion if the types of the LHS and RHS are different, but I'm thinking of dropping that, and requiring an explicit cast (with a new API entrypoint for that). The testsuite fully passes if I drop the implicit casts. Thoughts? Dave [1] fwiw the gcc::context in GCC proper is independent from the gcc::jit::context in gcc/jit/internal-api.[hc]. One day a jit context might own a gcc::context, perhaps.