Re: Alignment not supported?

[David Malcolm <dmalcolm@redhat.com>]

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 )