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


Eric Botcazou <ebotcazou@adacore.com> writes:

> > I don't see that in the code in tree-ssa-alias.c.  What am I not
> > seeing?
> 
> I was under the impression that it's precisely because there is no specific 
> code in the flow-sensitive aliasing part that this works for them like this 
> works for every other pointer. :-)

Sure, that is true, but nevertheless finalize_ref_all_pointers is
going to indicate that any REF_ALL pointer may point to any call
clobbered variable.  I don't see what stops that.


> > Reliably using is_escape_site does require using a different type, and
> > I didn't want to do that because of the difficulty in making sure that
> > it was handled correctly in all cases.  And because in C++ there
> > really is no change in type.  The type is exactly the same; there are
> > just some restrictions on the aliasing assumptions that can be made at
> > a specific point in the program.
> 
> You could devise something equivalent though: make CHANGE_DYNAMIC_TYPE_EXPR a 
> special "escape site", corresponding to a special SMT.  This would pessimize 
> less than making may_alias_p always return 1, although I don't know by how 
> much for typical C++ code.

As far as I can see that SMT would have to alias every other SMT in
order to correctly implement CHANGE_DYNAMIC_TYPE_EXPR, so I don't
think this would actually pessimize less.

Ian


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