Re: [Libjit] Stack alignment in 32-bit MinGW builds

[Eli Zaretskii]

> From: Jakob Löw <address@hidden>
> Date: Tue, 21 Aug 2018 01:20:39 +0200
> 
> According to what I found Microsoft's ABI does not specify a stack
> alignment on x86[0].

It is 4-byte aligned, see

  http://www.peterstock.co.uk/games/mingw_sse/

> Is there a reason why gcc aligns the stack on a 8 byte boundary?

First, I must correct myself: it's 16 bytes, not 8 bytes.  I've
misremembered.

As for the reason, I believe it's so GCC could emit SSE instructions
which require the alignment.

> What happens when an emacs object is not 8 byte aligned?

In that case, Emacs cannot create stack-based Lisp objects without
triggering errors and assertion violations all over the place.  And
even without stack-based objects, GCC might (and actually does) emit
SSE instructions, which will trigger fatal exceptions if fed unaligned
data.

> In my eyes what you want is non standard

Well, it's pretty standard with GCC, for the reasons described above.
We have a similar problem with callbacks of Windows APIs, but there
GCC provides the force_align_arg_pointer function attribute, which we
use for the few callbacks we have.  Libjit doesn't provide anything
similar, which is why I asked for it to be added, at least as an
opt-in feature.

> and should not be implemented
> into libjit but rather emacs should make sure to align the lisp objects
> (e.g. using gcc's align __attribute__).

The problem with this is that we'd need to mark a lot of functions
with this attribute, because libjit can theoretically call any of
them.  This would clutter the sources, and produce a performance
penalty, albeit a minor one.  So Emacs instead has a fallback method,
whereby it switches to heap-based objects (which is what I used once I
identified the issue) -- but that, too, has run-time penalty, as it
produces more GC cycles as side effect.

Therefore, being able to guarantee alignment through libjit code would
be a win for 32-bit MinGW programs.