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

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 11 Jun 2007, Ian Lance Taylor wrote:

> Let me reset the conversation a bit.  It seems to me that you are 
> arguing in favor of introducing additional dependencies which are not 
> represented in the IR.  And you are arguing against an approach which 
> represents everything explicitly and does not introduce additional 
> dependencies.

Sort of, yes, but that's not the only properties of both approaches.

> Your argument is, essentially, that the latter approach 
> is too complicated.  It seems to me that when choosing between 1) 
> introducing new hidden dependencies and 2) introducing complexity, one 
> needs a very high level of complexity indeed before you would pick 
> choice 1.  And I don't think my patch attains that level of complexity.  

I would agree here.  But you can only come to this conclusion if you see 
the above two cited arguments as blob together and in isolation as if they 
have no other properties.  Let me explain:

The complexity vs. hidden-deps tradeoff is not the only one here.  One 
other trade-off is the broadness of the solution (i.e. how many 
"problematic" cases are fixed), then there's compile time and similar 
measures.

Also, when just looking at the complexity vs. hidden-deps tradeoff: even 
there one has to take into account how problematic those hidden-deps are 
to handle, IMHO they can be handled fine in this case, but clearly others 
might disagree.  Of course I would feel better if I could think of a 
non-ugly way to represent the dependencies but the cause for even giving 
me those headaches is that I think your approach is not the most desirable 
one, not because of its complexity but because of its non-generality.

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.

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)?

> (You also mentioned the issue of different people having different
> opinions regarding validity, but I think that is a red herring.  We
> should pick which code we think is valid.  We shouldn't try to cater
> to more than one definition of the language.  It's hard enough to
> cater to just one.

That's exactly what I meant.  People read the standard in different ways, 
and hence form different opinions about what is valid.  Some even read it, 
and reject that it could possibly have meant what it says :-)  So IMHO 
it's better to be conservative where in doubt (and no other disadvantags 
come with that).


Ciao,
Michael.