[cfe-dev] Question about optimization of new and delete

[Nicola Gigante]

Il giorno 30/set/2013, alle ore 00:28, Chandler Carruth <chandlerc at google.com> ha scritto:

> 
> Heh, not really. We're just now getting the C++ standard fixed: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html

Uh, ok :)

> See the paper for the high level theory of what the standard allows (once it goes in). The current plan in Clang is to follow that paper's strategy of optimization even in older standard modes unless there is significant existing code broken by it.
>  

What could be broken? I think such source code might be quite perverse.. 

> We can do this, but it may cause an unacceptable growth in stack usage. Hal Finkel has recently started work on an optimization pass to do precisely this, and I'm helping review and get it into the tree. I would expect Clang to start doing this soon for small, constant size allocations.
> 

This applies to most common use cases, right? Most objects are little…
Anyway, what will be the criterion for the decision of which allocation to lower to the stack and which not (e.g. what does "small" mean)?
> 
> 
> 2) Can clang/llvm identify as a dead store a write to a piece of memory that will be delete?
> 
> void func(Class *obj) {
>     obj->member = 42; // Is this store removed?
>     delete obj;
> }
> 
> Compiling this exact code with -O3, I see the store still there.
> 
> Huh. No, I bet we miss this. This is almost certainly just a missed optimization that we should get.
> 
> 
> However, note that all of Clang's optimizations of this form are mostly conducted by the LLVM optimization libraries Clang is built on, and so the fix to this missed optimization will likely involve mostly a change to LLVM.

Yeah, of course. But what I don't know is how does LLVM know at IR-level that a call to _Znam allocates memory and is paired with a call to _Zdam that frees it? It's special knowledge about this symbols, or some attribute put there in the extern symbol declaration?
For example, for this dead store, can you model in the IR that the memory will be lost or do you need a special case in the dead store elimination pass? Anyway, is it C++ specific or is there some generic architecture to model dynamic allocation (I believed not)?

I ask this because in another project I'm writing a llvm-based compiler and I'll want to apply those kind of optimizations as well.

Maybe, it could be worth to use some intrisincs, lowered by a front-end specific pass, that model dynamic allocation primitives.
What do you think?

Thanks,
Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130930/ca9fc8d6/attachment.html>