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

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

Michael Matz <matz@suse.de> writes:

> On Mon, 11 Jun 2007, Ian Lance Taylor wrote:
> 
> > Michael Matz <matz@suse.de> writes:
> > 
> > > > But Richard's proposed rules will hurt optimization in some cases. They 
> > > > didn't hurt his particular test case.
> > > 
> > > Well, his testcase actually was SPEC2000, polyhedron and a couple of heavy 
> > > and not so heavy C++ programs.
> > 
> > Fair enough, but really the particular test case was the x86_64
> > processor, which is aggressively out-of-order and relatively immune to
> > instruction scheduling issues.
> 
> He tested on ia64 not x86-64, specifically because that one is sensitive 
> to scheduling.  See comment 154.

Sorry, my mistake.  I should have remembered that.

That is certainly better than I recalled, but I still don't find it
conclusive since our scheduling isn't all that great on the IA64.


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.  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.  But maybe that is just my personal bias.  I'd be happy to
hear from other people on this.  Or let me know if I've misrepresented
the argument.

(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.)

Ian