<div dir="ltr">On Sun, Sep 29, 2013 at 12:04 PM, Nicola Gigante <span dir="ltr"><<a href="mailto:nicola.gigante@gmail.com" target="_blank" class="cremed">nicola.gigante@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello.<br>
<br>
Probably this is an old enough question, sorry in this case.<br></blockquote><div><br></div><div>Heh, not really. We're just now getting the C++ standard fixed: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I was wondering which optimizations clang/llvm does (or can do, given restrictions from the standard)<br>
about the use of default new/delete operators.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In particular, I'm wondering about a couple of interesting cases:<br>
<br>
1) Can clang convert a call to default operator new to stack allocation, if it can prove that<br>
the lifetime of the allocated memory is the same as the enclosing scope?<br>
Would it be someway contrary to the standard or somewhat undesirable?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Currently, Clang only really does this when it can delete the allocation entirely, which is probably why you see confusing results from your testing.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2) Can clang/llvm identify as a dead store a write to a piece of memory that will be delete?<br>
<br>
void func(Class *obj) {<br>
    obj->member = 42; // Is this store removed?<br>
    delete obj;<br>
}<br>
<br>
Compiling this exact code with -O3, I see the store still there.<br></blockquote><div><br></div><div>Huh. No, I bet we miss this. This is almost certainly just a missed optimization that we should get.</div><div><br></div>
<div><br></div><div>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.</div>
</div></div></div>