[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 #155 from rguenther at suse dot de  2007-05-24 10:11 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
 new does not change the dynamic type as it should

On Thu, 24 May 2007, rguenther at suse dot de wrote:

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

Btw, in case you are curious - on 
http://www.suse.de/~gcctest/c++bench/tramp3d/split-run.html you can see
the effects of the asm() memory barrier as proposed by one of Ians patches
and the effect of forcing -fno-strict-aliasing on (the two spikes in
runtime, the later one is -fno-strict-aliasing, the earlier one is the 
asm()).  Both approaches disable moving loop invariant loads which is
one thing you retain with my proposed slightly changed TBAA rules.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286