Re: new module 'aligned-malloc'

[Jeffrey Walton]

On Tue, Jul 21, 2020 at 7:24 AM Bruno Haible <bruno@clisp.org> wrote:
>
> > Checkout  https://forum.kde.org/viewtopic.php?p=66274 for some info on
> > detection of posix_memalign.
>
> It's well-known that you can't use standards symbols like __STDC_VERSION__
> or _XOPEN_SOURCE for hardly anything. We wouldn't have hundreds of
> AC_CHECK_FUNC calls in gnulib/m4/ if they weren't needed.

Lol... yeah.

> > I think there's also another option, if interested. On x86 you can get
> > aligned allocations with _mm_malloc.
>
> _mm_malloc is not in the libc of any system I know of. The docs [1] state
> that it is a compiler built-in. If it relies on an Intel library, that
> would make it unsuitable for use in gnulib (since it would introduce an
> additional link dependency for something that should not need one).

As far as I know it's part of any compiler that supports Intel
processors with SSE.

> > And with PPC you can get an
> > aligned block with vec_malloc.
>
> On AIX, yes, not on Linux/PowerPC nor on Mac OS X/PowerPC. But the only
> documentation of this function that I can find [2] is not a reference
> documentation. Why would I use a function that has no reference documentation?

To avoid that alternate code.

> > As you probably know, Linux aligns heap allocations to 16 by default.
>
> It's the libc which does this, not the kernel. And glibc aligns malloc()
> results to 8 bytes on most 32-bit platforms.

I believe the runtime is required to return a pointer aligned for the
largest C type on the system. On x86 that's 16 bytes due to the xmm
datatypes.

Jeff