Re: Alignment not supported?

[David Malcolm <dmalcolm@redhat.com>]

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.

Dave