[MLton] x86_64 port status

[Matthew Fluet]

>> Perhaps a better approach would be to define the following:
>>
>>    struct PointerAux { unsigned char[4]; } __attribute__ ((aligned (4));
>>    typedef struct PointerAux* Pointer;
>
> I tried this out and it worked well.  To be clear, I used
>
>  struct PointerAux { unsigned char z[4]; } __attribute__ ((aligned (4)));

I've further added the "may_alias" attribute.  This prevents type-based 
alias analysis, just like using unsigned char did before.

> This cut down the number of "cast increases required alignment" warnings
> from 143 to 95.  All of the warnings eliminated were from basis/*
> files.  Only one such warning remains.
>
>  basis/Real/modf.c:10: warning: cast increases required alignment of target type

Not surprising, as that function is passed a Real64.real ref.  And, 
therefore, is a legitimate warning -- we aren't promising to align a 
double at 8bytes.  What I don't know is whether the gcc warning means that 
passing an unaligned pointer would lead to undefined behavior, or just 
that gcc is warning that it must be conservative and therefore might not 
produce as efficient code.

> The remaining warnings are all in gc/* files.  I looked at a few, and
> they stem from the mismatch between the fact that "Pointer" is aligned
> while various C pointer types are not.

No suprise that the change to the "Pointer" type didn't affect gc/* files, 
as that typedef isn't used there.  [The convention is that the types 
defined in ml-types.h are the C-names for ML types; Pointer is the C-name 
for ML array, vector, and ref types.  The GC is actually quite ignorant of 
ML types -- it cares only about ML objects and the characteristics implied 
by the object header.  Within gc/*, we pervasively use
   typedef unsigned char* pointer;
which gives us byte addressing with aliasing -- appropriate for the low 
level manipulation of the ML heap.]

> The only fix I see is to define a number of new types that reflect the 
> alignment constraint. For example, instead of GC_arrayCounter* we would 
> define a new type, GC_arrayCounter_ptr.

Even then, its not clear that we'll achieve the necessary alignment.