------- Comment #154 from rguenther at suse dot de 2007-05-24 10:07 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote: > Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement > new does not change the dynamic type as it should > > rguenther at suse dot de wrote: > > >> Whatever conservative > >> assumptions we want to make about "*p = 3" we could make about "new (p) > >> int" instead. > > > > True. I say making them about "*p = 3" is way easier as we are changing > > semantics of memory operations and *p = 3 is one, but placement new is > > not. > > I think I understand what you're saying here too; again, I'll restate to > make sure: > > (a) In the model where "*p = 3" changes the dynamic type of memory, we > don't need to do anything special to handle placement new. > (b) It's relatively easy to implement support for "*p = 3" changing the > dynamic type of memory. > (c) Therefore, it's relatively easy to fix our placement new problem. > > I agree with those statements too. > > However, I don't like this approach because I believe it will result in > inferior code. I think that you're looking at the proposed placement > new patches, then looking at what they do to a particular codebase, > which happens to use placement-new in an inner loop, and becoming > unhappy with the patches. I suspect that the changes required to > support the "*p = 3" model, while perhaps better for that case, will be > worse for many others. > > I can't prove that. But, I did implement TBAA after looking at what > other compilers did, specifically to improve performance of (ironically) > POOMA. So, I'm afraid that you're going to find that if we allow memory > writes to change the type of memory, that we will get worse performance. So I did some benchmarking with my two proposed patches (which I believe will fix all current issues - that I know of) on IA64 which should be sensitive to the more restrictive scheduling. [You can look yourself at the results starting from http://www.suse.de/~gcctest/, the run without the patches is from late May23th the run with the patch from early May24th] I'll try to summarize only here. - SPECfpu2000 shows both winners and loosers, the net change is slightly positive for -O3 and slightly negative for -O3 -funroll-loops (slightly means +3 points vs. -4 points) - SPECint2000 shows more variance in single tests, crafty winning for peak, parser loosing for base, eon winning overall, likewise bzip. Overall we get a drop in SPECint of about 3 points (0.3%) - Polyhedron is mostly the same, aermod regressing 1.5%, induct improving 1%. - The set of C++ benchmarks (including TraMP-3d, DLV, Boost wave and others) show no changes. Of course this doesn't prove anything - it only hints that it might be not as bad as you thought. And no, I don't have a Power6 machine to test on yet. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
