[libcxx] Patch/RFC: Avoid using ::operator new in the default allocator

[Chandler Carruth]

On Wed, Sep 25, 2013 at 2:43 PM, Marshall Clow <mclow.lists at gmail.com>wrote:

> On Sep 25, 2013, at 2:37 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
>
> > On Sep 25, 2013, at 2:14 PM, Benjamin Kramer <benny.kra at gmail.com>
> wrote:
> >
> >> Since N3664 was implemented in Clang (r186799) it can't optimize unused
> pairs of ::operator new and ::operator delete anymore. Calls generated by a
> new/delete expression are still foldable with the updated wording. This
> affects optimizing away unnecessary code that would be really nice to get
> right. For example
> >>
> >> #include <vector>
> >>
> >> int main() {
> >> std::vector<int> v;
> >> v.push_back(1);
> >>
> >> return v[0];
> >> }
> >>
> >> This should fold down to "return 1;" with no allocations. The example
> is of course oversimplified but situations like this easily occur in real
> world code through inlining.
> >>
> >> The proposed patch replaces "::operator new(x)" with "new char[x]" and
> adds the necessary casts in the allocator class, as suggested by Richard
> Smith. This is sufficient to constant fold code like my test case again.
> >
> > Is there some technical reason that clang cannot optimize away unused
> pairs of ::operator new/delete? (as opposed to "just doesn't do it any
> more" - not a real quote).
>
> Added in N3664:
>         An implementation is allowed to omit a call to a replaceable
> global allocation function (18.6.1.1, 18.6.1.2).
>
> To me, "replaceable global allocation function" --> ::operator new.


This only applies to calls made as part of a new expression -- an explicit
call cannot be transformed, it is allowed to have observed side effects
according to as-if.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130925/f40a5fc5/attachment.html>