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
