[LLVMdev] _Znwm is not a builtin

[Richard Smith]

On Wed, May 15, 2013 at 9:24 PM, Chris Lattner <clattner 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.
>
>
> Ugh.  Having two different ways to represent "the same" thing is deeply
> unfortunate.  I don't understand the full issue here though, how can you
> get an indirect call to ::operator new?  Can you take its address in C++?
>

Yes. operator new is an ordinary function that happens to have a funny
name, and can have its address taken.


> If you think the C code / weird cases are important,
>
>
> It is not (to me at least), I just want to understand the design point.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/8c87f17a/attachment.html>