This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [-ftree-cselim desoptimizes SH code
- From: Michael Matz <matz at suse dot de>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Christian BRUEL <christian dot bruel at st dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 28 Sep 2009 04:21:43 +0200 (CEST)
- Subject: Re: [-ftree-cselim desoptimizes SH code
- References: <4ABCA7CB.8020409@st.com> <mcrr5ttrnyf.fsf@dhcp-172-17-9-151.mtv.corp.google.com>
Hi,
On Sat, 26 Sep 2009, Ian Lance Taylor wrote:
> I believe this transformation is invalid under the C++0x memory model.
Well, if we choose to support this less than thrilling memory model then
we possibly have to disable the pass (or limit it) for C++0x, as well as
the vectorizer (and probably some other passes). No reason that other
languages have to suffer from the c++ committees decision to ignore
volatile and barriers to the disfavor of optimizing compilers.
Ciao,
Michael.
P.S: Btw. it's really funny (if it weren't so sad) to read e.g.
http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/c++mm.pdf . It
shows some nice examples what isn't possible with that crappy memory model
anymore. Without any words on how bad an idea that is. And without
really fixing the problem they try to solve (hardware reordering as
explained later in the same slides). Horrific. I'm not into committees
so much, but why they rejected the idea of marking the shared data as -
well - shared (which would immediately remove all performance problems),
is completely beyond me. They must have rejected it, as it's so obvious
that somebody there simply must have proposed it. That something like
this can get into a standard ... baffling.