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 RFA: PR 29286: Handle placement new aliasing issues


Michael Matz <matz@suse.de> writes:

> On Mon, 11 Jun 2007, Ian Lance Taylor wrote:
> 
> > It is safe to remove the CHANGE_DYNAMIC_TYPE_EXPR nodes because the 
> > first aliasing pass will record the information in DECL_NO_TBAA_P flags 
> > on the relevant decls.
> > 
> > The first aliasing pass needs the CHANGE_DYNAMIC_TYPE_EXPR nodes because 
> > it is necessary to propagate the information to all relevant pointers 
> > via the solver.  It does not suffice to set DECL_NO_TBAA_P in the 
> > frontend because the gimplifier can lose the information while creating 
> > new temporary variables.
> 
> But those new temporary vars are supposedly somehow connected (via 
> copying or offseting) to those vars which have DECL_NO_TBAA_P set.  So 
> couldn't that flag be simply propagated (I don't know, perhaps via 
> points-to) to all relevant decls?

I don't understand the reference to points-to; if you mean the alias
analysis code, that is exactly how the flag is propagated in my
proposed patch.

Note that the NO_TBAA flag is not initially a property of any user
variable.  It is a property of the pointer returned by a call to
placement new.  So we get code like

     D.XXXXX = &v;
     CHANGE_DYNAMIC_TYPE_EXPR <long *, D.XXXX>
     p = D.XXXXX

In particular p can be a field in a struct or an element in an array,
and we can later use SRA to turn it back into a variable.  In that
scenario we need to not lose the DECL_NO_TBAA_P property.

When I tried not using CHANGE_DYNAMIC_TYPE_EXPR at all, and just
setting DECL_NO_TBAA_P on D.XXXXX, the problem was that in several
test cases the temporary variable D.XXXXX simply dropped out.  To make
this work I would have to make the variable volatile, which would have
been bad for optimization, or I would have had to copy the
DECL_NO_TBAA_P flag during assignment and any other way that D.XXXXX
might be used.  That would have been a more invasive and more fragile
patch.  We already have code which knows how to copy properties to all
variables associated with each other: the graph produced by the
aliasing solver.  My patch uses that code.

I hope this makes sense.  Frankly, to me, the decision as to whether
to use my patch or whether to use implicit dependencies is a
no-brainer.  As another argument, my patch only affects programs which
use placement new, but implicit dependencies could affect any program.
(As noted in my original e-mail, I believe my patch could also be used
to slightly improve the optimization we currently apply to memcpy, but
I haven't experimented with that yet.  And in the other thread it
seems that my patch might be able to improve the optimization of Ada
ALIAS_ALL pointers, although I'm not certain.)

Ian


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