This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Constant-fold vector comparisons
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