[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

[dberlin at gcc dot gnu dot org]

------- Comment #25 from dberlin at gcc dot gnu dot org  2006-12-29 20:28 -------
So the solution for 4.3 here, from what i understand, seems pretty easy at the
tree level, no matter what reading we wish to give this.

If we add a placement_new_expr, and not try to revisit our interpretation of
the standard, we can just DTRT and fix placement new. This would be best for
optimizations, and IMHO, for users.

Otherwise, we are at the point in 4.3 (In the past month this has changed, it's
not really possible to backport this stuff to 4.2 very easily) where we have
two types of variables from an aliasing perspective:

SSA variables
Global/static variables

For both, we know if they are *actually* dereferenced (and not just escaping to
a call, and thus "possibly dereferenced").

SSA variables never escape, and all casting will have been done in a statement
that leads to the SSA variable. The SSA variable will only appear on the LHS
once  The only time they are currently pruned using TBAA information is at the
dereference site (IE b_3 = *foo_5).  This seems right to me, as it should have
the correct dynamic type at this point, and anywhere else we prune using TBAA
info without an explicit dereference is a bug.  Under the reading that stores
with different types are legal and start new object lifetimes, we would have to
change the pruning to only prune at *load* dereference sites.

Under this reading, we would never be able to reorder stores based on TBAA
because they are never illegal under the reading that they start new object
lifetimes.

For globals/statics ("bare variables"), we currently will prune even if they
are only "maybe-dereferenced".  I think this is a bug under our current
interpretation, and we should fix it.
Because bare variables may appear on the LHS multiple times, we have a couple
options, depending on the readings.

Note that any of these require IPA and in the case of true globals,
whole-program mode, in order to *ever be able to reorder a store/load based on
TBAA*. 

We could gather the types that occur, and prune at load dereference sites
assuming it is one of these, *if the variable does not escape the module*.

Most statics do escape through library calls that we could add attributes to,
but don't escape otherwise.
So without attributing, you will lose roughly 90-100% of TBAA enabled
store/load reordering of globals and statics.
With attributing, you will probably lose 10-20% of TBAA enabled *load*
reordering for statics, 100% of TBAA enabled reordering for globals (unless you
promote them), and 100% of TBAA enabled store reordering.
We could disable TBAA entirely for globals and statics, and you will just lose
100% everywhere :)

TBAA accounts for about 7-25% of alias disambiguations in the real world for C
and C++ (combined). This is according to both papers published by Intel about
ICC, papers published by MS about VC, papers published by IBM about XLC, and
testing of Google's codebase with and without -fno-strict-aliasing (with the
caveat that we know our codebase is not entirely strict aliasing safe)

That said, it is wildly variant from program to program as to how effective it
is, and pretty unpredictable just from staring at code.


I'll leave the decision about what we want to do up to someone else, i'm just
explaining the aliasing options we have. 


-- 


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