Re: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Dec 4, 2017 at 6:55 AM, Jeff Law <law@redhat.com> wrote:
> As we touched on in IRC, the EVRP analyzer was doing something stupid
> which caused it to not merge in existing range information under certain
> circumstances.
>
> Consider this fragment:
>
>   x_1 = foo ()
>   if (x_1 > 2)
>     __builtin_unreachable ();
>   if (x_1 < 0)
>     __builtin_unreachable ();
>
> Obviously the range for x_1 is [0,2] and we compute that range in the
> EVRP optimization pass as well as VRP.
>
> If a pass (say VRP) were to delete the __builtin_unreachable calls we'll
> be left with:
>
>
>   x_1 = foo ()
>
> Any subsequent EVRP analysis won't be able to generate range information
> for that statement -- ie, it looks like VR_VARYING.  Due to a dumb bug
> in the EVRP analysis we allowed that VR_VARYING to override any range
> that had been computed by an earlier VRP or EVRP pass.

Doh - probably not noticed because EVRP was only run "first" ...

>
> Fixing is trivial.  Always call update_value_range, even if the
> currently discovered range is VR_VARYING.
>
> Bootstrapped and regression tested, both in isolation and as part of
> this 3 part kit.
>
> OK for the trunk?

Ok.

Thanks,
Richard.

> Jeff
>
>         * gimple-ssa-evrp-analyze.c
>         (evrp_range_analyzer::extract_range_from_stmt):  Always use
>         vr_values::update_value_range so preexisting range info is
>         medged with new range info, even if the new range is VR_VARYING.
>
> diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c
> index 551b1d6..fb3d329 100644
> --- a/gcc/gimple-ssa-evrp-analyze.c
> +++ b/gcc/gimple-ssa-evrp-analyze.c
> @@ -271,8 +271,7 @@ evrp_range_analyzer::record_ranges_from_stmt (gimple *stmt)
>        edge taken_edge;
>        value_range vr = VR_INITIALIZER;
>        vr_values->extract_range_from_stmt (stmt, &taken_edge, &output, &vr);
> -      if (output
> -         && (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE))
> +      if (output)
>         {
>           vr_values->update_value_range (output, &vr);
>
>