------- Comment #142 from rguenther at suse dot de 2007-05-23 21:14 -------
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, mark at codesourcery dot com wrote:
> ------- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07
> -------
> Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
> new does not change the dynamic type as it should
>
> rguenth at gcc dot gnu dot org wrote:
>
> > <quote>
> > Gaby's claim is that given an arbitrary
> > pointer "p", saying:
> >
> > (int *)p = 3;
> >
> > is the same as saying:
> >
> > *(new (p) int) = 3;
> >
> > That makes life for the optimizers much, much harder.
> > </quote>
> >
> > I say so as well (that those are the same), but I don't agree that this
> > makes life for optimizers much harder.
>
> Placement new is rare; assignments to pointers are everywhere.
>
> Note that the first case does not need to use an explicit cast. In a
> function:
>
> void f(int *p) {
> *p = 3;
> }
>
> under Gaby's interpretation, we cannot be sure that "p" points to an
> "int" before this function, so we can't be sure the write to "*p"
> doesn't clobber memory of other types. TBAA is one of the few ways to
> disambiguate pointers in the absence of whole-program optimization, and
> this model really undermines TBAA.
In C inside the function f we can indeed be sure *p points to an "int".
Now what matters is, that even in C for
double g(int *p, double *d)
{
f(p);
return *d;
}
we cannot be sure (in absence of whole-program optimization or the
body of f available) that the call to f does not clobber *d through
the value of the pointer p. As it can look like
void f(int *p)
{
double *d = p;
*d = 1.0;
}
> Frankly, I'm surprised that you are taking this position. This is a
> change to the compiler that can only hurt high-performance C++
> applications, which is an area I know you care about. I know that
> you're unhappy about how Ian's patches might hurt programs that use
> placement-new in an inner loop, but this model will impose the same
> penalties on programs that write to pointers in an inner loop.
No it won't. Or at least - I belive so - unless I see a patch that
manages to implement placement new with the same minor restrictions.
If you discount scheduling on in-order machines, what would be an
optimization that can be no longer done with Gabys and my scheme?
I believe there are none. Also other compilers manage to not
miscompile in the face of placement new but still optimize loops
with them.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
