Here is the patch.
Thanks,
bin
On Thu, Nov 24, 2016 at 10:11 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
> On Thu, Nov 24, 2016 at 8:57 AM, Richard Biener
> <richard.guent...@gmail.com> wrote:
>> On Wed, Nov 23, 2016 at 3:57 PM, Bin.Cheng <amker.ch...@gmail.com> wrote:
>>> On Wed, Nov 23, 2016 at 2:27 PM, Richard Biener
>>> <richard.guent...@gmail.com> wrote:
>>>> On Wed, Nov 23, 2016 at 2:54 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>>>>> Hi,
>>>>> This is actually the review suggestion for patch
>>>>> @https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02341.html, but I forgot
>>>>> to incorporate it when committing that patch. Here comes this one doing
>>>>> that, as well as adding a missing convert keyword. Toolchain built
>>>>> successfully, is it OK?
>>>>
>>>> As said you _do_ need the outermost (convert ...) on the (max .. and
>>>> (min ... expressions given @1 may not be of type 'type'.
>>> Sorry about the stupid mistake. How about this one? The from_type in
>>> the last branch looks like necessary to me.
>>
>> I think
>>
>> (if (code == EQ_EXPR)
>> (cond (cmp @1 (convert @3)) (convert @3) @2)))))))
>>
>> is better? We want the outer expression of type 'type' and @2 is
>> already 'type',
>> only @3 may not be. So the only change would be to dop the unnecessary
>> :from_type inside the cmp and the bogus :from_type on the true arg of the
>> cond.
> Hi Richard,
> The idea of using from_type in EQ_EXPR case is to do cond_expr in
> narrow/from type for all its operands, then convert the result back to
> default type.
> - (cond (cmp @1 (convert:from_type @3)) (convert:from_type @3) @2)))))))
> + (convert (cond (cmp @1 (convert @3))
> + (convert:from_type @3) (convert:from_type @2)))))))))
>
> Is it better than using different types for operand 0 and 1/2 in cond_expr?
> I updated the patch following your suggestion. Note, in this way
> below range check on @2 should be redundant for EQ_EXPR case, but I
> didn't change that in this patch.
>
> if (int_fits_type_p (@2, from_type)
> && (types_match (c1_type, from_type)
> || (TYPE_PRECISION (c1_type) > TYPE_PRECISION (from_type)
> && (TYPE_UNSIGNED (from_type)
> || TYPE_SIGN (c1_type) == TYPE_SIGN (from_type))))
>
> So which one should be preferred?
>
> Thanks,
> bin
>>
>> Richard.
>>
>>
>>> Thanks,
>>> bin
>>>>
>>>>> Thanks,
>>>>> bin
>>>>>
>>>>> 2016-11-23 Bin Cheng <bin.ch...@arm.com>
>>>>>
>>>>> * match.pd: Refine type conversion in result expressions for below
>>>>> pattern:
>>>>> (cond (cmp (convert1? x) c1) (convert2? x) c2) -> (minmax (x c)).
Index: gcc/match.pd
===================================================================
--- gcc/match.pd (revision 242751)
+++ gcc/match.pd (working copy)
@@ -2022,12 +2022,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
}
}
(if (code == MAX_EXPR)
- (convert (max @1 (convert:from_type @2)))
+ (convert (max @1 (convert @2)))
(if (code == MIN_EXPR)
- (convert (min @1 (convert:from_type @2)))
+ (convert (min @1 (convert @2)))
(if (code == EQ_EXPR)
- (cond (cmp @1 (convert:from_type @3)) (convert:from_type @3) @2)))))))
+ (cond (cmp @1 (convert @3)) (convert @3) @2)))))))
+
(for cnd (cond vec_cond)
/* A ? B : (A ? X : C) -> A ? B : C. */
(simplify
