On Mon, Oct 15, 2012 at 3:51 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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.
Ok, indeed. > 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. Ah no, I didn't mean to suggest that ;) > >> 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. I'm not sure either - I'd rather leave the possibility open until we see a compelling reason to go either way (read: a testcase where it matters in practice). >> 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. Yes, guarding against VEC_COND_EXPR is definitely needed. Richard. > Thanks, > > -- > Marc Glisse