From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29608 invoked by alias); 27 Mar 2017 16:38:44 -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 29590 invoked by uid 89); 27 Mar 2017 16:38:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=invent X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7F54A624C0 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dmalcolm@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7F54A624C0 Message-ID: <1490632719.11099.66.camel@redhat.com> Subject: Re: Alignment not supported? From: David Malcolm To: Florian Weimer Cc: =?UTF-8?Q?=EC=A0=95=EC=9D=B8=EB=B0=B0=28Inbae?= "Jeong)" , jit@gcc.gnu.org Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: <1490630429.11099.60.camel@redhat.com> References: <87fui1pj74.fsf@mid.deneb.enyo.de> <1490622483.11099.31.camel@redhat.com> <87wpbaojxb.fsf@mid.deneb.enyo.de> <1490630429.11099.60.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 27 Mar 2017 16:38:41 +0000 (UTC) X-SW-Source: 2017-q1/txt/msg00016.txt.bz2 On Mon, 2017-03-27 at 12:00 -0400, David Malcolm wrote: > On Mon, 2017-03-27 at 16:48 +0200, Florian Weimer wrote: > > * David Malcolm: > > > > > My first thought was that we could add a way to expose attributes > > > on types from the API, something like: > > > > > > extern gcc_jit_type * > > > gcc_jit_type_add_attribute (gcc_jit_type *type, > > > const char *attribute_name, > > > /* some extra params */ ); > > > > > > but it's not clear to me what those extra params should look like > > > here. > > > > > > It could be variadic, but variadic functions make for an error > > > -prone > > > API that's easy to crash, and they're a pain to deal with in > > > language bindings. > > > > Right, please don't do that. :) > > > > > Maybe: > > > > > > extern gcc_jit_type * > > > gcc_jit_type_add_attribute_int (gcc_jit_type *type, > > > const char *attribute_name, > > > int attr_param); > > > > > > (perhaps adding other suffixes for other type signatures; this is > > > a > > > C API, so there we can't use overloads; the C++ bindings could > > > use > > them, though). > > I would suggest to model the interface after > > gcc_jit_context_new_call > > (but still keep it separate because even though attributes with > > arguments are syntactically pretty much like function calls in the > > C > > front end, semantically, they are not). > > If I understand you right, this would give something like: > > extern gcc_jit_type * > gcc_jit_type_add_attribute (gcc_jit_type *type > const char *attribute_name, > int numargs, gcc_jit_rvalue **args); > > Is every attribute arg an rvalue though? Can some of them be types? > > If so, maybe we should use gcc_jit_object instead: > > extern gcc_jit_type * > gcc_jit_type_add_attribute (gcc_jit_type *type > const char *attribute_name, > int numargs, gcc_jit_object **args); > > so that for the motivating example: > > struct my_arg { > int a; > int b __attribute__ ((aligned (32))); > }; > > we'd have: > > 1: gcc_jit_type *int_type = gcc_jit_context_get_type(ctxt, > GCC_JIT_TYPE_INT) > 2: gcc_jit_field *field_a = gcc_jit_context_new_field(ctxt, NULL, > int_type, "a"); > > > gcc_jit_object *alignment > = gcc_jit_rvalue_as_object > (gcc_jit_context_new_rvalue_from_int (ctxt, int_type, 32)); > > gcc_jit_type *aligned_int_type > = gcc_jit_type_attribute (int_type, > "aligned", > 1, &alignment); > > 3a: gcc_jit_field *field_b = gcc_jit_context_new_field(ctxt, NULL, > aligned_int_type, "b"); > > > > > 4: gcc_jit_field *fields[2] = {field_a, field_b}; > 5: gcc_jit_struct *my_arg = gcc_jit_context_new_struct_type(ctxt, > NULL, "my_arg", 2, fields); > > > > > I'm not sure where the argument list checking for attributes > > happens > > (at least it's not part of the C parser). It would be preferable > > if > > there were at least some consistency checks when using the JIT > > interface, instead of silently generating broken code. > > (nods) > > It strikes me that a lot of the attributes are frontend-specific; see > for example gcc/c-family/c-attribs.c > (Also, LTO is often the place to look for things that are frontend > -specific but perhaps shouldn't be, or, at least, can need > duplicating > in libgccjit; I see some attribute handlers there in gcc/lto/lto > -lang.c) > > Am poking at this, to see exactly what happens in C frontend for this > case. > The attribute in question is this entry in c-attribs.c c_common_attribute_table[25]: { "aligned", 0, 1, false, false, false, handle_aligned_attribute, false }, which calls: handle_aligned_attribute, which effectively implements the attribute. Hence all of this pre-existing logic for setting the alignment of a type is implemented with the c-family front-end code, which isn't available from libgccjit. We could still invent attributes for the JIT, and aim for compatibility with the C family (maybe refactoring things). Alternatively, it might make more sense to go with this earlier API idea: extern gcc_jit_type * gcc_jit_type_set_alignment (gcc_jit_type *type, int alignment); or similar ("make_aligned" ? "add_alignment" ?) I think I prefer the latter approach, as it makes it explicit in client code linkage metadata what functionality it's using, whereas with the attribute-based approach it's hard to tell what attributes a particular client binary might make use of (similar to how I switched to new entrypoints for new options; see gcc_jit_context_set_bool_allow_unreach able_blocks() and https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#libgccjit- abi-2 )