[cfe-dev] aligned 'new'

[Anton Yartsev]

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!

-- 
Anton

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aligned_new_part1.patch
Type: text/x-diff
Size: 6961 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110624/12e623b0/attachment.patch>