On Thu, Oct 11, 2012 at 1:20 AM, Marc Glisse wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>> On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
>>>
>>> On Mon, 8 Oct 2012, Richard Guenther wrote:
>>>
> VEC_COND_EXPR is more complicated. We could for instance require that
> it
>
On Mon, 8 Oct 2012, Richard Guenther wrote:
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
thing a
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>>> VEC_COND_EXPR is more complicated. We could for instance require that it
>>> takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
>>> thing are equivalent). Which would leave
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
thing are equivalent). Which would leave to decide what the expansion of
vec_cond_expr passes to the target
On Fri, Oct 5, 2012 at 5:01 PM, Marc Glisse wrote:
> [I am still a little confused, sorry for the long email...]
>
>
> On Tue, 2 Oct 2012, Richard Guenther wrote:
>
> + if (TREE_CODE (op0) == VECTOR_CST && TREE_CODE (op1) == VECTOR_CST)
> +{
> + int count = VECTOR_CST_NELTS (
[I am still a little confused, sorry for the long email...]
On Tue, 2 Oct 2012, Richard Guenther wrote:
+ if (TREE_CODE (op0) == VECTOR_CST && TREE_CODE (op1) == VECTOR_CST)
+{
+ int count = VECTOR_CST_NELTS (op0);
+ tree *elts = XALLOCAVEC (tree, count);
+ gcc_assert (TREE
On Mon, Oct 1, 2012 at 5:57 PM, Marc Glisse wrote:
> [merging both threads, thanks for the answers]
>
>
> On Mon, 1 Oct 2012, Richard Guenther wrote:
>
optabs should be fixed instead, an is_gimple_val condition is
implicitely
val != 0.
>>>
>>>
>>> For vectors, I think it should be v
[merging both threads, thanks for the answers]
On Mon, 1 Oct 2012, Richard Guenther wrote:
optabs should be fixed instead, an is_gimple_val condition is implicitely
val != 0.
For vectors, I think it should be val < 0 (with an appropriate cast of val
to a signed integer vector type if necessar
On Fri, Sep 28, 2012 at 6:55 PM, Marc Glisse wrote:
> On Fri, 28 Sep 2012, Richard Guenther wrote:
>
>> On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse
>> wrote:
>>>
>>> Hello,
>>>
>>> I have been experimenting with generating VEC_COND_EXPR from the
>>> front-end,
>>> and these are just a couple th
On Fri, 28 Sep 2012, Richard Guenther wrote:
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
Hello,
I have been experimenting with generating VEC_COND_EXPR from the front-end,
and these are just a couple things I noticed.
1) optabs.c requires that the first argument of vec_cond_expr be
On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote:
> Hello,
>
> I have been experimenting with generating VEC_COND_EXPR from the front-end,
> and these are just a couple things I noticed.
>
> 1) optabs.c requires that the first argument of vec_cond_expr be a
> comparison, but verify_gimple_assig
Hello,
I have been experimenting with generating VEC_COND_EXPR from the
front-end, and these are just a couple things I noticed.
1) optabs.c requires that the first argument of vec_cond_expr be a
comparison, but verify_gimple_assign_ternary only checks
is_gimple_condexpr, like for COND_EXPR.
12 matches
Mail list logo