Re: making the new if-converter not mangle IR that is already vectorizer-friendly

[Alan Lawrence <alan dot lawrence at arm dot com>]

Abe wrote:
> <personal introduction/>

Hi, pleased to meet you :)

> <topic introduction>
>
> 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?


Thanks, Alan