[cfe-dev] aligned 'new'

Anton Yartsev anton.yartsev at gmail.com
Mon Jul 11 14:22:21 PDT 2011

On 24.06.2011 5:43, Anton Yartsev wrote:
> On 30.05.2011 8:35, Chris Lattner wrote:
>> On May 29, 2011, at 8:49 PM, Anton Yartsev wrote:
>>> Hi all,
>>> I am thinking of the ability of operator new to return memory aligned
>>> according to the alignment of the type passed to it (at least of 
>>> AltiVec
>>> vector types whose proper alignment is essential).
>>> The proposed implementation is:
>>> 1) clang: add -fstrict-aligned option. When the option is set it cause
>>> clang to define the built-in macro "__STRICT_ALIGNED"
>>> 2) libcxx: add additional placement new declarations to
>>> libcxx\include\new with the additional argument - alignment. Make this
>>> declarations conditionalized on the "__STRICT_ALIGNED". Add new
>>> definitions to libcxx\src\new.cpp.
>>> 3) clang: if -fstrict-aligned option is set, when clang sees a new of a
>>> type which either has an inherent alignment, or has an explicit
>>> alignment specified by __attribute__((__aligned__(x))), it will
>>> transform the standard new call to a call to the aligned version of 
>>> new.
>>> Am i on the right way? Any thoughts?
>> I don't think that this is the right way to go.  Instead, you'd want 
>> "new foo" to automatically detect that the alignment of "foo" is 
>> greater than the alignment guaranteed by the system malloc.  In this 
>> case, and if using the default operator new, you'd generate a call to 
>> memalign instead of to operator new (something like that).
>> It isn't clear to me how generally useful this is though, and we tend 
>> to avoid adding tons of language extensions to Clang.
>> -Chris
> Attached is the the patch that substitutes calls to default new 
> operators with calls to functions - aligned analogs of default new 
> operators. This functions may live in the clang's mm_malloc.h header 
> where aligned malloc lives.  The patch is partial, it does not affect 
> deletes and do not contain substituting functions yet. Please review 
> and direct!


More information about the cfe-dev mailing list