[LLVMdev] _Znwm is not a builtin

[Richard Smith]

On Wed, May 15, 2013 at 9:42 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On May 15, 2013, at 9:10 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Wed, May 15, 2013 at 8:57 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On May 15, 2013, at 8:50 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>
>> 1) The 'nobuiltin' attribute doesn't actually prevent the optimization
>>>>>> (see recent patch on llvmcommits)
>>>>>> 2) We can't block the optimization if the call happens through a
>>>>>> function pointer, unless we also annotate all calls through function
>>>>>> pointers as 'nobuiltin'
>>>>>>
>>>>>> How feasible would it be to make the 'builtin-ness' of _Znwm etc be
>>>>>> opt-in rather than opt-out? Is there some other option we could pursue?
>>>>>>
>>>>>
>>> Wow, this was spectacularly unclear, sorry about that. To avoid
>>> confusion, I'm suggesting that we add a 'builtin' attribute, and do not
>>> treat a call to _Znwm as a builtin call unless it has the attribute.
>>>
>>>
>>>
>>> It's not clear to me that "builtin" is the right way to model this, but
>>> it definitely sounds like this should be an attribute on a call site (as
>>> opposed to on the function itself).  What specific kinds of optimizations
>>> are we interested in doing to _Znwm calls?
>>>
>>
>> Initially, I'm just concerned about keeping the optimizations we already
>> perform, such as globalopt lowering a new/delete pair into a global, while
>> disabling the non-conforming variations of those optimizations. But we're
>> also permitted to merge multiple allocations into one if they have
>> sufficiently similar lifetimes.
>>
>>
>> So your proposal is for Clang to slap the attribute on explicit calls to
>> ::operator new, but any other use of the symbol (e.g. from C code or
>> something else weird) can be optimized?
>>
>
> No, because Clang cannot statically detect which indirect calls might call
> ::operator new. Instead, my proposal is to add a 'builtin' attribute to
> LLVM, and then for clang to add that attribute to the calls which can be
> optimized.
>
> If you think the C code / weird cases are important, a more nuanced option
> springs to mind:
>
> * Allow the 'nobuiltin' attribute on function declarations
> * Add a 'builtin' attribute, permitted only on direct calls to 'nobuiltin'
> functions, which overrides the 'nobuiltin' attribute on the function
>
> Would that be preferable?
>
>
> Just curious: will this fix the issue that we discussed last month in the
> context of r179071 regarding the need to compile with -fno-builtin if you
> have code with custom new operators? (
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/170888.html
> )
>

It would fix the problem if that operator new is being called explicitly,
but not if it's being called via a new-expression. The recent change to the
C++ standard doesn't address whether we're required to respect the inital
value of the memory produced by a user replacement operator new, but that
may well be covered by the normal C++ lifetime rules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/987f1336/attachment.html>