This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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