[Bug libstdc++/29286] [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" <gcc-bugzilla at gcc dot gnu dot org>]

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