From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4444 invoked by alias); 29 Dec 2006 20:28:38 -0000 Received: (qmail 4417 invoked by uid 48); 29 Dec 2006 20:28:28 -0000 Date: Fri, 29 Dec 2006 20:28:00 -0000 Message-ID: <20061229202828.4416.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dberlin at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg02078.txt.bz2 ------- 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