On Oct 5, 2013, at 8:59 PM, Chandler Carruth <[email protected]> wrote:
> > On Sat, Oct 5, 2013 at 8:15 PM, Howard Hinnant <[email protected]> > wrote: > On Sep 25, 2013, at 3:46 PM, Chandler Carruth <[email protected]> wrote: > > > 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. > > It seems illogical to me to allow one transformation but not the other > because of backwards compatibility concerns. And this seems to indicate that > the committee *does* have backwards compatibility concerns. > > The discussion in the committee around this basically centered around the > following logic: > > There was strong consensus that we wanted to allow these transformations to > most allocations. There was also strong consensus that it would be useful to > provide an escape hatch. Further, it seemed like the implementation providing > storage for a new expression by emitting optimized calls to the allocation > function would be relatively unsurprising, where as the implementation > merging *explicit* calls to operator new would be significantly more > surprising. > > Essentially, this wasn't a backwards compatibility decision, but one of > providing a relatively unsurprising mechanism to explicitly get an exact call > to an allocation function. > > I see a few ways forward, none of them easy, nor actionable by us alone. > > 1. Get the LWG to change the places where they specify calls to ::operator > new. This will entail a backwards compatibility hit. Not sure if it is > acceptably small or not. > > 2. Get the CWG to further relax where these types of optimizations can be > done. This will entail a backwards compatibility hit. Not sure if it is > acceptably small or not. > > 3. There's a new polymorphic allocator on the horizon. Make the spec for > that sufficiently relaxed for these optimizations, and get it standardized. > > Perhaps I'm missing another possibility? > > I don't think we need to do anything in the committee. > > I propose that we add a __builtin_allocate and __builtin_array_allocate (or > better names, i hate naming things) which call the global operator new > exactly as a new-expression would. That is, they *are* candidates for > merging, etc. Then we define the libc++ routine __allocate in terms of the > builtin. The result will be that calling libc++'s __allocate funtion does > call operator new, but when and how many calls are produced is unspecified. > > Essentially, the [allocator.members]p6 I believe already gives us enough > freedom to do the same set of optimizations as provided by the committee's > new wording for new-expressions. (It actually gives more freedom as far as I > can tell.) All we need is a way to express that to the optimizer. > > Does this make sense to you Howard? I may be missing some aspect of > incompatibility, so let me know. I must admit to not completely understanding how your path forward is any different from the status-quo. And in that sense, I have absolutely no objection to it. I do maintain that unless there is a committee change, we need to beware of: #include <vector> int main() { std::vector<int> v; v.push_back(1); return v[0]; } #include <stdio.h> #include <stdlib.h> void* operator new[](size_t sz) { printf("I don't like new-array!\n"); abort(); return nullptr; } And I do agree that these are very attractive optimization opportunities that we should aggressively pursue. Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
