[llvm-dev] Default alignment for 'malloc'

[Pete Cooper via llvm-dev]

> 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>