From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12693 invoked by alias); 23 May 2007 14:38:23 -0000 Received: (qmail 12630 invoked by alias); 23 May 2007 14:38:02 -0000 Date: Wed, 23 May 2007 14:38:00 -0000 Message-ID: <20070523143802.12629.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: "rguenther at suse dot de" 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: 2007-05/txt/msg02042.txt.bz2 ------- Comment #128 from rguenther at suse dot de 2007-05-23 15:37 ------- 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, ian at airs dot com wrote: > ------- Comment #127 from ian at airs dot com 2007-05-23 15:23 ------- > Re comment #105. > > The case where TBAA is most useful is on a deeply pipelined in-order processor > with multiple function units and a high latency memory cache. One example I've > worked on is an embedded VLIW processor with vector instructions. TBAA is of > relatively little interest on an out-of-order processor. > > It's interesting to talk about PTA when you see the actual objects and you see > how the pointers are taken. But in practice many real functions simply take > pointers to arrays in memory. PTA can say nothing useful about those pointers, > since they could point to anything. TBAA can say a lot. > > Losing the ability to sinks loads across stores and vice-versa means putting > additional constraints on the scheduler which makes it harder to exploit the > multiple function units. Conversely, it constrains the register allocator by > tending to extend register lifetimes. Sure, scheduling is one of the places we sink loads or hoist stores. > > Also, in your list of cases, you missed > x = *int; > *double = 1.0; > x = *int; > With TBAA we can eliminate the second load as a duplicate. With your proposed > aliasing change we can not. We still can. We can hoist the second load before the store and so make both loads load the same value. The fact that there is a second load of int after the store to double disambiguates the two memory locations. > I don't understand why you argue in comment #124 that our current scheme will > esverely penalize placement new. On mainline there is no penalty for placement > new. So you must be referring to one of the patches. Yes, I was refering to patches that make changes to forbid sinking a load across a store. With our current IL this will also forbid hoisting a loop-invariant load - which is the key to good performance on tramp3d. > But I don't think we've > agreed on any of them at the moment. And I think we see the outlines of a > successful patch: make placement new return a pointer which effectively aliases > everything. That will permit us to reorder loads and eliminate dead stores. > It won't permit us to arbitrarily re-order loads and stores, but I'm skeptical > that that will count as a severe penalty. But... void foo(int *p) { float *f = (float *)p; new (p) float; *f = 1.0; } there is no "new pointer" from placement new. All placement new does is (magically) change the dynamic pointed-to type. Or would you argue the above is invalid? It is hard to make non-trivial cases work and not impose a full memory barrier at the point of the placement new. In the above case you would need to make the alias sets of float conflict with everything in which case only trivial cases will allow to DSE stores to float or hoist loads of floats. As I said - with our current IL design I see no nice way to express the constraints placement new sets without imposing more constraints than necessary. (This is also true for my proposed changes -- those constraints would be implicit in the IL, just optimization passes would not need to look for PLACEMENT_NEW_EXPRs but simply follow rules if they do optimizations on memory operations) Maybe to find a compromise how about making PLACEMENT_NEW_EXPR effective only after RTL expansion? So, during tree optimization completely ignore it (from the alias IL representation perspective) and follow the changed rules I proposed and after RTL expansion make placement new effects explicit, like by merging target type alias sets with alias set zero. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286