Why align all pinned array payloads on 16 bytes?

[Simon Marlow]

I don't imagine anyone wants to align to anything that's not a power of 2,
or less than a word size. Still, unless the current generality results in
extra complication or overheads I wouldn't change it.

On Mon, 22 Oct 2018 at 11:44, Ömer Sinan Ağacan <omeragacan at gmail.com>
wrote:

> Thanks for all the answers. Another surprising thing about the pinned
> object
> allocation primops is that the aligned allocator allows alignment to bytes,
> rather than to words (the documentation doesn't say whether it's words or
> bytes,
> but it can be seen from the code that it's actually aligning to the given
> byte). Is there a use case for this or people mostly use alignment on word
> boundaries?
>
> Ömer
>
> Sven Panne <svenpanne at gmail.com>, 17 Eki 2018 Çar, 10:29 tarihinde şunu
> yazdı:
> >
> > Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow <
> marlowsd at gmail.com>:
> >>
> >> I vaguely recall that this was because 16 byte alignment is the minimum
> you need for certain foreign types, and it's what malloc() does.  Perhaps
> check the FFI spec and the guarantees that mallocForeignPtrBytes and
> friends provide?
> >
> >
> > mallocForeignPtrBytes is defined in terms of malloc (
> https://www.haskell.org/onlinereport/haskell2010/haskellch29.html#x37-28400029.1.3),
> which in turn has the following guarantee (
> https://www.haskell.org/onlinereport/haskell2010/haskellch31.html#x39-28700031.1
> ):
> >
> >    "... All storage allocated by functions that allocate based on a size
> in bytes must be sufficiently aligned for any of the basic foreign types
> that fits into the newly allocated storage. ..."
> >
> > The largest basic foreign types are Word64/Double and probably
> Ptr/FunPtr/StablePtr (
> https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1700008.7),
> so per spec you need at least an 8-byte alignement. But in an SSE-world I
> would be *very* reluctant to use an alignment less strict than 16 bytes,
> otherwise people will probably hate you... :-]
> >
> > Cheers,
> >    S.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181024/bba62a79/attachment.html>