From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4032 invoked by alias); 27 Mar 2017 13:48:38 -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 3816 invoked by uid 89); 27 Mar 2017 13:48:21 -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=0.6 required=5.0 tests=BAYES_00,GARBLED_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=jit, JIT, H*Ad:U*jit X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,GARBLED_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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 822CE680E5 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dmalcolm@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 822CE680E5 Message-ID: <1490622483.11099.31.camel@redhat.com> Subject: Re: Alignment not supported? From: David Malcolm To: =?UTF-8?Q?=EC=A0=95=EC=9D=B8=EB=B0=B0=28Inbae?= "Jeong)" , Florian Weimer Cc: jit@gcc.gnu.org Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: References: <87fui1pj74.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 27 Mar 2017 13:48:05 +0000 (UTC) X-SW-Source: 2017-q1/txt/msg00012.txt.bz2 On Sat, 2017-03-25 at 23:05 +0900, 정인배(Inbae Jeong) wrote: > Sorry for being too short. It's JIT mailing list so I thought > everyone > would expect it to be related to gccjit. > > I'm writing a small JITed interpreter and trying to call an external > C > function (actually it is an external "C" C++ function) of which one > of > the parameters is a struct containing an aligned member variable. > > To make a struct type with gccjit, it will be somewhat like this: > > struct my_arg { > int a; > alignas(32) int b; > }; > > 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"); > 3: gcc_jit_field *field_b = gcc_jit_context_new_field(ctxt, NULL, > int_type, "b"); // How do I specify the alignment? > 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); > > > Maybe the alignment should be specified in line 3 or a new int type > has to be made with alignment specification, if supported. However I > don't see anything about alignment in the gccjit manual. I don't think that there's currently a way to do this from libgccjit. 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. 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). Alternatively, we could have a special-case entrypoint: extern gcc_jit_type * gcc_jit_type_set_alignment (gcc_jit_type *type, int alignment); and hide the fact that it's an attribute internally. I'm not yet sure which approach I prefer (and maybe I need to poke at this from the implementation side to see what's implementable). What other attributes might people want to use? Thoughts? Dave