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