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

[Howard Hinnant]

On Sep 25, 2013, at 2:46 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> 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.

20.8.9.1 [allocator.members]/p6:

> Remark: the storage is obtained by calling ::operator new(std::size_t) (18.6.1), but it is unspec- ified when or how often this function is called. The use of hint is unspecified, but intended as an aid to locality if an implementation so desires.

The question becomes, if we make this substitution, is there a test the user can write to observe it?  Is there an LWG issue here?

Howard