llvm dev - Oct 2016 - Default alignment for 'malloc'

On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev
wrote:
> 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev
> <llvm-dev at lists.llvm.org>:
> > I am trying to implement some new alignment based optimisations in our
> > target backend, and I am wondering if there a way a target can specify
that
> > ‘malloc’, ‘realloc’ and ‘calloc’ always return a pointer to memory
that is
> > aligned to a particular boundary?
> 
> malloc is guaranteed to be properly aligned for any C type. This would
> be 8 bytes on most systems for double. However, I think in practice
> most modern implementations return 16-byte aligned pointers. I don't
> think there is a way to annotate calls malloc to have some specific
> alignment from the backend, that has effect on passes before the
> backend.
Note that this only applies to base types. Vector types certainly can
require larger alignment in practice and that's why posix_memalign
exists.

Joerg

> On Oct 3, 2016, at 11:01 AM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev wrote:
>> 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev
>> <llvm-dev at lists.llvm.org>:
>>> I am trying to implement some new alignment based optimisations in
our
>>> target backend, and I am wondering if there a way a target can
specify that
>>> ‘malloc’, ‘realloc’ and ‘calloc’ always return a pointer to memory
that is
>>> aligned to a particular boundary?
>> 
>> malloc is guaranteed to be properly aligned for any C type. This would
>> be 8 bytes on most systems for double. However, I think in practice
>> most modern implementations return 16-byte aligned pointers. I
don't
>> think there is a way to annotate calls malloc to have some specific
>> alignment from the backend, that has effect on passes before the
>> backend.
> 
> Note that this only applies to base types. Vector types certainly can
> require larger alignment in practice and that's why posix_memalign
> exists.
Is memalign stil needed for vector types?  From the man page
(http://www.manpagez.com/man/3/calloc/
<http://www.manpagez.com/man/3/calloc/>), it says:

The malloc(), calloc(), valloc(), realloc(), and reallocf() functions allocate
memory.
The allocated memory is aligned such that it can be used for any data type,
including AltiVec- and SSE-related types.

Given this, a while ago I had a hacked up an LLVM pass to add align(16) to the
return attributes of malloc.  It saved a few KB from the clang executable size
due to more efficient memcpy and related functions being generated in the
backend.

So yes please to some kind of solution to this.  I’d be fine with adding
something to TTI if we can’t get it in the headers.

Cheers,
Pete
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/dcd81002/attachment.html>

On Mon, Oct 03, 2016 at 12:23:12PM -0700, Pete Cooper
wrote:
> 
> > On Oct 3, 2016, at 11:01 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > 
> > On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev
wrote:
> >> 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev
> >> <llvm-dev at lists.llvm.org>:
> >>> I am trying to implement some new alignment based
optimisations in our
> >>> target backend, and I am wondering if there a way a target can
specify that
> >>> ‘malloc’, ‘realloc’ and ‘calloc’ always return a pointer to
memory that is
> >>> aligned to a particular boundary?
> >> 
> >> malloc is guaranteed to be properly aligned for any C type. This
would
> >> be 8 bytes on most systems for double. However, I think in
practice
> >> most modern implementations return 16-byte aligned pointers. I
don't
> >> think there is a way to annotate calls malloc to have some
specific
> >> alignment from the backend, that has effect on passes before the
> >> backend.
> > 
> > Note that this only applies to base types. Vector types certainly can
> > require larger alignment in practice and that's why posix_memalign
> > exists.
> Is memalign stil needed for vector types?
If you want to be portable to more than one libc implementation, yes.
Base alignment on i386 is still 32bit only for example in the SysV ABI.
I'm not even sure what the requirements for AVX is, e.g. if they finally
bumped it to 256bit for some things.

Joerg

2016-10-03 20:01 GMT+02:00 Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org>:
>> malloc is guaranteed to be properly aligned for any C type. This would
>> be 8 bytes on most systems for double. However, I think in practice
>> most modern implementations return 16-byte aligned pointers. I
don't
>> think there is a way to annotate calls malloc to have some specific
>> alignment from the backend, that has effect on passes before the
>> backend.
>
> Note that this only applies to base types. Vector types certainly can
> require larger alignment in practice and that's why posix_memalign
> exists.
You are right and I should have remembered: BlueGene/Q has 32 byte
vector types, and I was using posix_memalign for those. IBM certainly
would not change the system base alignment of PowerPC because of this.

posix_memalign would still have another use case: Alignment to cache
line boundaries.

Michael