https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #12)
> I was looking at this again tonight, and I clearly missed the interaction
> between known ranges and the overflow check.
>
> If we look at the .vrp1 dump we see this overflow check in bb16:
>
> 23 = ASSERT_EXPR <_13, _13 > 2>;
> _1 = _23 + 18446744073709551614;
> if (_1 > _23)
> goto <bb 17>; [33.00%]
> else
> goto <bb 41>; [67.00%]
>
> This is a controlling condition for the clearing loop which ldist will turn
> into a memset.
>
> The range for _23 is:
>
> (gdb) p debug_value_range (get_value_range (gimple_cond_rhs (stmt)))
> [3, +INF] EQUIVALENCES: { _13 } (1 elements)
>
> Exactly what we'd expect given the ASSERT_EXPR. So far so good.
>
> The condition can be rewritten as _23 - 2 > _23, which is only going to be
> true if _23 has the value 0 or 1. So we can deduce that the condition is
> always false.
>
> We're correctly identifying the test as an overflow check in VRP, but we're
> not optimizing it. I think we just need to extend
> vr_values::vrp_evaluate_conditional_warnv_with_ops and the right things
> should just happen.
In fact if we'd do it like EVRP (set SSA_NAME_RANGE_INFO) then IMHO
stmt folding via gimple_fold_stmt_to_constant_1 should handle it
without adding "tricks" to vrp_evaluate_conditional_warnv_with_ops.
That said, this function should likely call match-and-simplify somehow
(note that match.pd lacks a pattern that would simplify the above with
range information).
That said, doing this somewhere more generic (match.pd) might be better,
though VRP not setting range-info during propagation might make things
harder here.
