[MLton] latest MLton segfault in gmp

[Wesley W. Terpstra]

On Wed, Oct 14, 2009 at 11:56 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:

> I'm hardly an expert.  I used the www.x86-64.org document to implement
> the C calling convention in the native codegen, but didn't peruse it
> much otherwise.
>

Nice link, thanks.


> Searching for "align" in the document, though, reveals that on page
> 12, it declares that  {,signed,unsigned} {,long} long  all have 8-byte
> alignment.


Ok, that table is pretty clear. The ABI defines that Word64s must be 8-byte
aligned. Therefore gcc was within it's rights to assume that the pointer was
8-byte aligned and the bug was ours.


>  However, on the next page it states:


>  Like the Intel386 architecture, the AMD64 architecture in general
> does not re-
>  quire all data accesses to be properly aligned. Misaligned data
> accesses are slower
>  than aligned accesses but otherwise behave identically. The only
> exceptions are
>  that __m128 and __m256 must always be aligned properly.
>

This is not a contradiction. Architecture != ABI. The machine can do it, but
the ABI forbids it.

So, it isn't clear to me that one really needs to 8-align 64-bit integers.
>

If we want to link with any other application code ... libc, libgmp, ffi,
.... then it's 100% clear we need to do 8-byte alignment. We have just been
lucky that no other software actually made use of the 8-byte alignment
guarantee until now (since few architectural limitations actually trip over
an ABI violation).


> In the next subsection (p. 13), on aggregates and unions, it states:
>
>  An array uses the same alignment as its elements, except that a
> local or global array variable of length at least 16 bytes or a C99
> variable-length
> array variable always has alignment of at least 16 bytes.
>

I think by global/local arrays they mean arrays not in the heap but the data
segment. (local = static int64_t foo[4];, global = extern int64_t foo[4];)

At any rate, this sounds like we don't need to worry because MLton only
passes arrays as pointers (both FFI and GMP limb structure).

I did want to also point out that there is a legacy issue, I would
> assume, on Debian.  Since mlton-20070826 is dynamically linked against
> libgmp, isn't it just an incredible luck of the draw that a
> self-compile with mlton-20070826 didn't happen to produce a
> non-16-byte aligned IntInf array.
>

Yes, I was surprised too. However there are a couple reasons this worked
out. First, the only code gcc managed to vectorize in the gmp C is the
MPN_ZERO method. Second, the only place MPN_ZERO gets called (for us) is to
clear the low bits of a left-shifted intinf. Third, it won't use 16-byte
writes unless there are 16-bytes to write, so it had to be a >=128-bit left
shift. I wonder if these maybe didn't happen in 20070826?

I imagine that as gcc gets smarter, vectorizing more code, this will become
a more serious legacy issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20091015/20b367c3/attachment.html