On Sep 25, 2013, at 2:46 PM, Chandler Carruth <[email protected]> wrote:

> 
> On Wed, Sep 25, 2013 at 2:43 PM, Marshall Clow <[email protected]> wrote:
> On Sep 25, 2013, at 2:37 PM, Marshall Clow <[email protected]> wrote:
> 
> > On Sep 25, 2013, at 2:14 PM, Benjamin Kramer <[email protected]> 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



_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to