Fw: [lno] [RFC] if-conversion and auto vectorizer

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> I will also be doing the following soon (after MIN/MAX becomes gimple
> which has already be discussed and approved):

I seem to have missed the MIN/MAX discussion thread. Do you have a link to
that, or was it off the mailing list? just curious when is it planned to
add the MIN/MAX tree codes to gimple and who is responsible for that?

> But I have not thought about the if-conversions which you are asking
> for yet.

Since the ABS, MIN/MAX, etc. are special cases of the if-conversion we are
proposing, it looks like there will be an overlap between what we plan to
implement, and the transformations that will take place during phiopt,
which made us wonder whether it would make sense to implement our
transformation during phiopt as well. For example, in the case of ABS:

bb0:
      x = src[i]
      if (x < 0) GOTO BB1
            else GOTO BB2
bb1:
      x' = -x
bb2:
      x'' = PHI <x', x>
      dst[i] = x''

In the general case, the if-conversion we're proposing would transform it
into:

bb0:
      x = src[i]
      C = CMP (x < 0)
      x' = -x
      x'' = "SELECT" C, x', x
      dst[i] = x''

and in special cases (like ABS, saturation, etc) we would then (or before
hand) detect the special pattern and further optimize it as follows:

bb0:
      x = src[i]
      x'' = ABS x
      dst[i] = x''

Our main concern is that we don't know that this transformation is
desirable in the general case - we know its desirable when it enables
vectorization, but we're not sure we want to be blindly replacing
IF-THEN-ELSE's with SELECT's (or COND_EXPR) all over the place (it would
result in doing a lot of transform-IF-THEN-ELSE-into-SELECT during phiopt
followed by expand-SELECT-into-IF-THEN-ELSE during RTL expand).

Therefore, we originally thought of creating the "SELECT" patterns just
before the vectorizer, in places that are candidate for vectorization
(loops), and revert them back to if-then-else right after vectorization if
they don't get vectorized. This way, "SELECT"s will only be present after
vectorization, and only in vector form (operating on vector data types),
which is somewhat less intrusive (only passes that come after vectorization
may encounter SELECTs, and we also won't need to worry about expanding
SELECTs back to if-the-else during RTL expand).

However, considering that a lot of ifcvt functionality is going to take
place in phiopt, maybe phiopt is the right place for our ifcvt after all?
this way, there would be only one pass that performs all ifcvt-related
opts, and no danger of duplicating work (we don't want to end up
implementing a pass that will become obsolete as phiopt pass is being
enhanced). Please advise...

thanks,
Dorit and Devang



                                                                                                                                
                      Andrew Pinski                                                                                             
                      <pinskia@physics.        To:       Devang Patel <dpatel@apple.com>                                        
                      uc.edu>                  cc:       "gcc@gcc.gnu.org list" <gcc@gcc.gnu.org>, Dorit                        
                                                Naishlos/Haifa/IBM@IBMIL, Andrew Pinski <pinskia@physics.uc.edu>                
                      04/03/2004 22:12         Subject:  Re: [lno] [RFC] if-conversion and auto vectorizer                      
                                                                                                                                




There are already some if-conversions on the tree-ssa right now, they
are
called PHI OPTs and in tree-ssa-phiopt.c, I am trying to add some more
right
now but they most likely will be added to the LNO branch after an other
merge from the tree-ssa branch.

Right now on the tree-ssa the following optimization is done:
if (a == b) 1 else 0 into a == b

Right now I add the following:

if (a >= 0) a else -a into ABS (a).
if (a != b) a else b into a.

I will also be doing the following soon (after MIN/MAX becomes gimple
which has already be discussed and approved):
if (a >= b) a else b into MAX (a, b)
if (a <= b) a else b into MIN (a, b).

But I have not thought about the if-conversions which you are asking
for yet.

Thanks,
Andrew Pinski