[LLVMdev] _Znwm is not a builtin

Chris Lattner clattner at apple.com
Thu May 16 10:13:38 PDT 2013

On May 15, 2013, at 10:32 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>> 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.

To be clear, I'm only objecting because I don't want to add complexity to the IR for such a weird corner case.

Just brainstorming here, and yes, this is somewhat horrible, but would it be possible to handle this by having IRGen introduce a "thunk" function in the case when ::operator new has its address taken?

For example, you could have this pseudo code:

	auto FP = & ::operator new;  // I have no idea how to actually spell this in C++

IRGen into the equivalent of:

	static void *thunk(size_t NumBytes) {
	  return ::operator new(NumBytes);   // Direct call, with nobuiltin attribute set.

	auto FP = thunk;

That way the pain of this corner case is hoisted into clang, instead of subjecting all consumers of LLVM IR to a complexity increase.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130516/824f6d56/attachment.html>

More information about the llvm-dev mailing list