This is the mail archive of the
mailing list for the GCC project.
Re: making the new if-converter not mangle IR that is already vectorizer-friendly
- From: Alan Lawrence <alan dot lawrence at arm dot com>
- To: Abe <abe_skolnik at yahoo dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>
- Date: Thu, 02 Jul 2015 10:30:38 +0100
- Subject: Re: making the new if-converter not mangle IR that is already vectorizer-friendly
- Authentication-results: sourceware.org; auth=none
- References: <55946699 dot 4070803 at yahoo dot com>
Hi, pleased to meet you :)
As some of you already know, at SARC we are working on a new "if converter" to help convert
simple "if"-based blocks of code that appear inside loops into an autovectorizer-friendly form
that closely resembles the C ternary operator ["c ? x : y"]. GCC already has such a converter,
but it is off by default, in part because it is unsafe: if enabled, it can cause certain code
to be transformed in such a way that it malfunctions even though the non-converted code worked
just fine with the same inputs. The new converter, originally by my teammate Sebastian Pop,
is safer [almost-always safe *]; we are working on getting it into good-enough shape that the
always-safe transformations can be turned on by default whenever the autovectorizer is on.
* Always safe for stores, sometimes a little risky for loads:
speculative loads might cause multithreaded programs with
insufficient locking to fail due to writes by another thread
being "lost"/"missed", even though the same program works OK
"by luck" when compiled without if-conversion of loads.
This risk comes mainly/only from what the relevant literature
calls a "half hammock": an "if" with a "then" section but no
"else" section [or effectively vice-versa, e.g. an empty "then"
and a non-empty "else"]. In this case, e.g. "if (c) X[x] = Y[y];"
with no attached "else" section is risky to fully if-convert
in the event of the code being compiled running multithreaded
and not having been written with all the locking it really needs.
Respectively, e.g. "if (c) ; /* empty ''then'' */ else X[x] = Y[y];".
For the unenlightened, can you outline the problem with this code sequence?
(i.e. the expected transformation that makes it unsafe!?) I would hope your
scratchpad patch would turn this into something like
a1 = c ? &Y[y] : &scratch;
temp = *a1;
a2 = c ? &X[x] : &scratch;
*a2 = temp;
which seems OK to me - so is the scratchpad approach going away?
(The problem that things might be read in a different order *across* the
elements of a vector, I can see, but that belongs in the domain of the
vectorizer itself, not if-conversion, I would think?)
One of the reasons the new if converter has not yet been submitted
for incorporation into GCC`s trunk is that it still has some
performance regressions WRT the old converter, and most of those
are "true regressions", i.e. not just because the old converter
was less safe and the additional safety is what is causing the loss,
but rather because there is more work to do before the patch is ready.
As of this writing, the new if converter sometimes tries
to "convert" something that is already vectorizer-friendly,
and in doing so it renders that code now-NOT-vectorizer-friendly.
Can you give an example? My understanding was that the existing vectorizer
bailed out pretty much straightaway if the number of basic blocks in the loop
was not exactly 2 (for inner loops) or 5 (for outermost loops, i.e. containing
exactly one inner loop)...that seems to rule out vectorization of *any* kind of
conditional execution, that the if-converter might convert?