[LLVMdev] _Znwm is not a builtin
Richard Smith
richard at metafoo.co.uk
Wed May 15 20:44:15 PDT 2013
On Wed, May 15, 2013 at 8:28 PM, Richard Smith <richard at metafoo.co.uk>wrote:
> On Wed, May 15, 2013 at 7:49 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
>> On Wed, May 15, 2013 at 8:31 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>>
>>> Hi,
>>>
>>> LLVM classifies _Znwm as a builtin by default. After some discussion,
>>> the C++ core working group have decreed that that is not correct: calls to
>>> "operator new" *can* be optimized, but only if they come from
>>> new-expressions, and not if they come from explicit calls to ::operator
>>> new. We cannot work around this in the frontend by marking the call as
>>> 'nobuiltin' for two reasons:
>>>
>>> 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.
> I think we should just fix this when we build the system which allows
>> optimizing new expressions. Specifically, when we introduce a way to mark
>> new expressions for LLVM to optimize, that's the time to make the
>> builtin-ness of _Znwm opt-in instead of opt-out.
>>
>
> This 'builtin' attribute would *be* building the system which allows
> optimizing new-expressions.
>
> Suggested transition plan:
> 1) add 'builtin' attribute
> 2) make Clang use it
> 3) make _Znwm and friends not be implicitly builtin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130515/0305e831/attachment.html>
More information about the llvm-dev
mailing list