On Mon, 15 Oct 2012, Richard Biener wrote:

       else if ((code == BIT_NOT_EXPR
                && TYPE_PRECISION (TREE_TYPE (cond)) == 1)
               || (code == BIT_XOR_EXPR
-                  && integer_onep (gimple_assign_rhs2 (def_stmt))))
+                  && ((gimple_assign_rhs_code (stmt) == VEC_COND_EXPR)
+                      ? integer_all_onesp (gimple_assign_rhs2 (def_stmt))
+                      : integer_onep (gimple_assign_rhs2 (def_stmt)))))

I don't think that we can do anything for vectors here.  The non-vector
path assumes that the type is a boolean type (thus two-valued), but
for vectors we can have arbitrary integer value input.

Actually, we just defined VEC_COND_EXPR as taking only vectors of -1 and 0 as its first argument. So if it takes X^-1 or ~X as first argument (looks like I forgot the ~ case), then X is also a vector of -1 and 0.

I liked your idea of the signed boolean vector, as a way to express that we know some vector can only have values 0 and -1, but I am not sure how to use it.

Thus, as we defined true to -1 and false to 0 we cannot, unless relaxing what VEC_COND_EXRP treats as true or false, optimize any of ~ or ^ -1 away.

It seems to me that what prevents from optimizing is if we want to keep the door open for a future relaxation of what VEC_COND_EXPR accepts as its first argument. Which means: produce only -1 and 0, but don't assume we are only reading -1 and 0 (unless we have a reason to know it, for instance because it is the result of a comparison), and don't assume any specific interpretation on those other values. Not sure how much that limits possible optimizations.

Which means I'd prefer if you simply condition the existing ~ and ^
handling on COND_EXPR.

Ok, that situation probably won't happen soon anyway, I just wanted to do something while I was looking at this region of code.

Thanks,

--
Marc Glisse

Reply via email to