Alignment of Lisp_Subr

[Stefan Monnier]

So I have finally gotten around to move my tags from the top 3 to the
bottom 3 bits of a Lisp_Object so that Lisp_Objects can now be allocated
anywhere.

Here are the problems I'm facing (all of them due to the new constraint
that objects need to be aligned on 8 byte boundaries) and I'm wondering what
is the best solution for them:

- Lisp_Misc has currently a size that is not a multiple of 8.
  I solved that by adding some padding with

   /* A miscellaneous object, when it's on the free list.  */
   struct Lisp_Free
     {
       int type : 16;   /* = Lisp_Misc_Free */
       unsigned gcmarkbit : 1;
       int spacer : 15;
       union Lisp_Misc *chain;
   #ifdef USE_LSB_TAG
       /* Try to make sure that sizeof(Lisp_Misc) is a multiple of 8.
          This assumes that Lisp_Marker is the largest of the alternatives.  */
       char padding[8 * ((sizeof (struct Lisp_Marker) - 1) / 8 + 1)
                    - sizeof (struct Lisp_Intfwd)];
   #endif
     };

  I think this solution is acceptable since it only increases the size
  of Lisp_Misc objects from 5 words to 6 words (i.e. by 20%) on typical
  32bit machines.  Maybe we could reduce this cost by making use of this
  extra word, although I'm not sure how.

- Structures of type Lisp_Subr are statically allocated and are not
  guaranteed to be aligned on a multiple of 8.  I currently solve this
  by adding __attributes__ ((__aligned__ (8))), but this only works for GCC
  AFAIK.  The only alternative I can think of is to add a padding field
  to Lisp_Subr and when its address is not a multiple of 8, memmove it
  by a few bytes (I think `defsubr' is the only place where we refer
  to these statically allocated Sfoo variables).
  Any comment on which approach is preferable ?

- malloc does not guarantee on all systems that the returned value
  will be a multiple of 8 (or does it?).  How can I check it so as
  to automatically determine whether I can set USE_LSB_TAG (i.e. in
  `configure').  Is a heuristic check of calling malloc a few times
  with a few different odd sizes sufficient?


        Stefan