On Sun, Jun 28, 2015 at 1:45 PM, Marc Glisse wrote:
> On Fri, 26 Jun 2015, Richard Biener wrote:
>
> OK. The reason I was being paranoid was that I couldn't see anywhere
> where we enforced that the vector condition in a VEC_COND had to have
> the same element width as the values bein
On Fri, 26 Jun 2015, Richard Biener wrote:
OK. The reason I was being paranoid was that I couldn't see anywhere
where we enforced that the vector condition in a VEC_COND had to have
the same element width as the values being selected.
We don't require that indeed.
tree-cfg.c
only checks t
On Fri, Jun 26, 2015 at 12:39 AM, Marc Glisse wrote:
> On Wed, 24 Jun 2015, Richard Biener wrote:
>
>> On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse
wrote:
>
> On Tue, 23 Jun 2015
On Wed, 24 Jun 2015, Richard Biener wrote:
On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford
wrote:
Richard Biener writes:
On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse wrote:
On Tue, 23 Jun 2015, Richard Sandiford wrote:
+/* Vector comparisons are defined to produce all-one or all-zer
On Thu, Jun 25, 2015 at 1:51 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Thu, Jun 25, 2015 at 10:15 AM, Richard Sandiford
>>> Index: gcc/match.pd
>>> ===
>>> --- gcc/match.pd2015-06-24 20:24:31.344998571 +0100
Richard Biener writes:
> On Thu, Jun 25, 2015 at 10:15 AM, Richard Sandiford
>> Index: gcc/match.pd
>> ===
>> --- gcc/match.pd2015-06-24 20:24:31.344998571 +0100
>> +++ gcc/match.pd2015-06-24 20:24:31.340998617 +0100
>
On Thu, Jun 25, 2015 at 10:15 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford
>> wrote:
>> There is precedence for different
>> expansion paths dependent on optabs (or even rtx cost?). Of course
>> expand_unop doesn't get t
Richard Biener writes:
> On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford
> wrote:
> There is precedence for different
> expansion paths dependent on optabs (or even rtx cost?). Of course
> expand_unop doesn't get the original tree ops (expand_expr.c does,
> where some special-
On 06/24/2015 05:43 AM, Richard Biener wrote:
Note that ISTR code performing exactly the opposite transform in
fold-const.c ...
That's another reason why I'm worried about just doing the (negate ...)
thing without knowing whether the negate can be folded into anything else.
I'm not aware of
On Wed, Jun 24, 2015 at 3:37 PM, Richard Sandiford
wrote:
There is precedence for different
expansion paths dependent on optabs (or even rtx cost?). Of course
expand_unop doesn't get the original tree ops (expand_expr.c does,
where some special-casing using get_gimple_for_expr
>>> There is precedence for different
>>> expansion paths dependent on optabs (or even rtx cost?). Of course
>>> expand_unop doesn't get the original tree ops (expand_expr.c does,
>>> where some special-casing using get_gimple_for_expr is). Not sure
>>> if expand_unop would get 'cond' in a form w
On Wed, Jun 24, 2015 at 2:28 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Jun 24, 2015 at 1:10 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
>> I'm fine with using tree_nop_conversion_p for now.
>
> I like the suggestion about checking TYPE_VECTOR_SU
Richard Biener writes:
> On Wed, Jun 24, 2015 at 1:10 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
> I'm fine with using tree_nop_conversion_p for now.
I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element
mode. How about:
(if (VECTO
On Wed, Jun 24, 2015 at 1:10 PM, Richard Sandiford
wrote:
> Richard Biener writes:
I'm fine with using tree_nop_conversion_p for now.
>>>
>>> I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element
>>> mode. How about:
>>>
>>> (if (VECTOR_INTEGER_TYPE_P (type)
>>> &
Richard Biener writes:
>>> I'm fine with using tree_nop_conversion_p for now.
>>
>> I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element
>> mode. How about:
>>
>> (if (VECTOR_INTEGER_TYPE_P (type)
>> && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0
On Wed, Jun 24, 2015 at 11:57 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse wrote:
>>> On Tue, 23 Jun 2015, Richard Sandiford wrote:
>>>
+/* Vector comparisons are defined to produce all-one or all-zero results.
*/
+(simplif
Richard Biener writes:
> On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse wrote:
>> On Tue, 23 Jun 2015, Richard Sandiford wrote:
>>
>>> +/* Vector comparisons are defined to produce all-one or all-zero results.
>>> */
>>> +(simplify
>>> + (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
>>> + (if
On Tue, Jun 23, 2015 at 11:27 PM, Marc Glisse wrote:
> On Tue, 23 Jun 2015, Richard Sandiford wrote:
>
>> +/* Vector comparisons are defined to produce all-one or all-zero results.
>> */
>> +(simplify
>> + (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
>> + (if (tree_nop_conversion_p (type, TRE
On Tue, 23 Jun 2015, Richard Sandiford wrote:
+/* Vector comparisons are defined to produce all-one or all-zero results. */
+(simplify
+ (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
+ (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
+ (convert @0)))
I am trying to understand why the
19 matches
Mail list logo
