Re: PATCH RFA: PR 29286: Handle placement new aliasing issues

[Ian Lance Taylor <iant at google dot com>]

Michael Matz <matz@suse.de> writes:

> And perhaps also because I still couldn't convince myself that your 
> approach really fixes the problem for good, and doesn't introduce 
> too much pessimization (I'm aware that right now tramp3d doesn't regress, 
> but you already noted that this hardly is a representative set).  AFAIR 
> when I discussed this with Richard we weren't sure if the problem is 
> fixable for good with something like CHANGE_DYNAMIC_TYPE_EXPR without 
> inhibiting optimizers heavily.

To be honest, it's difficult for me to be concerned about excessive
pessimization with placement new.  I pushed the patch as far as I did
because Richard was concerned by it, and had a relevant test case.
But I remain skeptical that there is a lot of high performance C++
code which uses placement new in inner loops.  It simply isn't needed.
The STL provides a documented way to avoid it: uninitialized_fill.  It
just happens that tramp3d for some reason elects not to use that.

> For instance: in order to gain back the lost performance you have 
> introduced removing the new nodes after alias1.  Why is that safe?  Why 
> does the TBAA in later alias[2-6] stages not reintroduce the problem, 
> although it has no CHANGE_DYNAMIC_TYPE_EXPR nodes anymore.  And if it is 
> safe, why does the first aliasing pass need them (instead of for instance 
> rely on the frontend to do whatever is done for the alias2-6 passes)?

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.

Ian