This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR38503, re-implement no-tbaa (placement-new, GIMPLE_CHANGE_DYNAMIC_TYPE)


On Mon, 26 Jan 2009, Daniel Berlin wrote:

> On Mon, Jan 26, 2009 at 2:15 AM, Richard Guenther <rguenther@suse.de> wrote:
> > On Sun, 25 Jan 2009, Richard Guenther wrote:
> >
> > Well, indeed.  The problem here is that we are attacking the problem
> > with a flow-insensitive solution, so whenever we have no clue which
> > memory we change the dynamic type of (the pointer points to
> > anything) we have to effectively fall back to -fno-strict-aliasing.
> > Without IPA or even whole-program PTA this is the usual case, not
> > the exception.
> 
> Without context-sensitive PTA, this would still be the case for
> non-whole programs with any externally visible function call in the
> chain that was passing pointers (which is, well, most of them).

Yep :/

> > Which simply means that trying to attack the problem this way is not
> > going to work - unless, of course, you implement it in an incomplete
> > way like we do now ;).
> 
> Well, actually, you could do something like the SMT implementation,
> and create one "anything variable" per type and use them during PTA.
> This would effectively give you TBAA results out of PTA, and let you
> implement change dynamic type by adding the right "anything variable"
> to the constraints at the CHANGE_DYNAMIC_TYPE site.

Of course we don't know the "right" variable.  I assume you are
thinking of doing PTA for types, thus tracking what types a
pointer _must_ alias (that is, it _must_ alias all the types
in its may-points-to-set if it is dereferenced, independent of
its own pointed-to type)?  Of course as any must-alias problem
it is impossible to compute this always correct (while still
being more useful as regular object PTA).  So - I don't think
this will help at all ;)

For adding some more confusion consider

void foo(void *p, int *i, float *f)
{
  *i = 1;
  new (p) float;
  *f = 1;
}

all pointers point to anything here.  You say i points to the int SMT,
f points to the float SMT.  We don't know what SMT p points to - it
is not dereferenced directly (but as all pointers point to anything
it may well be dereferenced, either as int or float in this case).
So we end up needing to say that we may not apply TBAA rules to
any aliased object (thus, what i, f and p point to).

Or, to make it more complicated

int i;
void foo(void *p, float *f)
{
  i = 1;
  new (p) float;
  *f = 1;
}

We generally use 'i' as the memory tag for i = 1; but with your
scheme we'd either need to add ints SMT and floats SMT or add
an int alias to floats SMT.  And this just out of seeing
the CHANGE_DYNAMIC_TYPE on p ... or because p points to anything
and we again say TBAA is a no-no for this function.

It's just bad.  Way better if we make a barrier work, because that
will give us flow-sensitivity.  And if we just adjust our memory
model a bit so that stores always may change the dynamic type of
memory it will be even asymmetric for loads - which is the
optimal thing we can get.

Oh well ;)

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]