Attempting to unbox struct fields

[David Thompson]

Hello wingo and list,

A couple days ago on #guile, I started a conversation about optimizing
some record types I use for linear algebra to take advantage of unboxed
arithmetic in the upcoming Guile 2.2.  Andy informed me of a temporary
hack I could try, but then said that The Right Thing is for Guile to
unbox struct fields.  So, I thought since Andy wrote such a nice post on
his blog about about Guile compiler tasks [0] that maybe I would give it
a try!  I have gone about as far as I can on my own (not far), and seek
the guiding light of the Guile maintainers to help unblock me.

The task is as follows, quoting from the above mentioned blog post:

    Guile's "structs", on which records are implemented, support unboxed
    values, but these values are untyped, not really integrated with the
    record layer, and always boxed in the VM. Your task would be to
    design a language facility that allows us to declare records with
    typed fields, and to store unboxed values in those fields, and to
    cause access to their values to emit boxing/unboxing instructions
    around them. The optimizer will get rid of those boxing/unboxing
    instructions if it can. Good luck!

I took an exploratory romp around the codebase and here's what I've
learned:

- Guile indeed supports unboxed fields in the struct implementation.
  Currently it only supports unboxed unsigned integers, but there's some
  preprocessor magic that can be removed to enable unboxed signed
  integers and doubles:

      switch (field_type)
      {
      case 'u':
        data[p] = SCM_NUM2ULONG (3, val);
        break;
      
      #if 0
      case 'i':
        data[p] = SCM_NUM2LONG (3, val);
        break;
      
      case 'd':
        *((double *)&(data[p])) = scm_num2dbl (val, (char *)SCM_ARG3);
        break;
      #endif

      ...

- It's easy enough to create a vtable with unboxed fields:

    (define vtable (make-vtable "uwuw"))
    (define s (make-struct vtable 123 456))
    (struct-ref s 0) ;; => 123

- struct-ref/immediate and struct-set!/immediate are the VM operations
  for reading from/writing to structs

- Roughly speaking, in the case of unboxed unsigned integers, one would
  want to insert a scm->u64 instruction before setting the value of an
  unboxed field, and one would want to insert a u64->scm instructor
  after getting the value of an unboxed field.

- In TreeIL, struct refs and sets are primcalls, and when compiling to
  CPS they receive some special treatment to unbox the index component
  of the respective operations.  This might be the procedure that will
  insert the boxing/unboxing instructions for the struct fields, but I'm
  not sure.

Now that I've learned a little bit, I have a bunch of questions that I
cannot yet answer:

- Is it possible to know the layout of a vtable at compile time?

- If so, where is that information stored?

- If not, does this mean that TreeIL needs to be changed to be able to
store typed struct field data in order to generate the correct CPS?

- Can the TreeIL format even be reasonably changed since its a public
interface that people target when writing their own language
implementations?

Basically, how could I possibly get my hands on the vtable information
at compile time?

Help would be very much appreciated!

Thanks,

-- 
David Thompson
GPG Key: 0FF1D807

[0] http://wingolog.org/archives/2016/02/04/guile-compiler-tasks