Comments

On Sat, 29 Sep 2012, Marc Glisse wrote:
> 1) it handles constant folding of vector comparisons,>> 2) it fixes another place where vectors are not expected
Here is a new version of this patch.
In a first try, I got bitten by the operator priorities in "a && b?c:d",
which g++ doesn't warn about.
2012-10-12 Marc Glisse <marc.glisse@inria.fr>
gcc/
* tree-ssa-forwprop.c (forward_propagate_into_cond): Handle vectors.
* fold-const.c (fold_relational_const): Handle VECTOR_CST.
gcc/testsuite/
* gcc.dg/tree-ssa/foldconst-6.c: New testcase.

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,

On Mon, Oct 15, 2012 at 3:51 PM, Marc Glisse <marc.glisse@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