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

[mark at codesourcery dot com]

------- Comment #146 from mark at codesourcery dot com  2007-05-23 22:13 -------
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:

> Only so much that we seem to agree on the semantics of placement new.
> Gaby extends this semantics to any store, so
> 
>   *p = X;
> 
> is equivalent to
> 
>   *(new (p) __typeof__ *p) = X;
> 
> to which semantics we thus can agree (not to whether those two should
> be the same, mandated by the standard or liked by some of us or not).

I think I understand.  Let me just restate this, to make sure:

(a) Gaby's model makes the first assignment above equivalent to the second
(b) Thus, in Gaby's model, if we solve either case, we solve both.

I agree with that statement.  (I don't like the model -- but I agree
with the logic.)

>> Making "*p = 3" change the dynamic type of "*p" can't possibly help us
>> implement placement new more efficiently.
> 
> I disagree here.  Making "*p = 3" change the dynamic type of "*p" will
> make the placement new issue moot - the current library implementation
> is fine then and we don't need any new explicit or implicit side-effects
> of it.
> 
>> 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.

That's why I'm much more comfortable with a change that only affects
placement new.  At least, if placement new is slow, we can tell users
not to use it in inner loops.  If using pointers are slow, there's
nothing we can do.


-- 


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