This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH GCC11]Improve uninitialized warning with value range info


On Wed, Jan 8, 2020 at 6:01 AM bin.cheng <bin.cheng@linux.alibaba.com> wrote:
>
> Sorry, here is the patch.
> ------------------------------------------------------------------
> Sender:bin.cheng <bin.cheng@linux.alibaba.com>
> Sent At:2020 Jan. 8 (Wed.) 12:58
> Recipient:GCC Patches <gcc-patches@gcc.gnu.org>
> Subject:[PATCH GCC11]Improve uninitialized warning with value range info
>
>
> Hi,
>
> Function use_pred_not_overlap_with_undef_path_pred of pass_late_warn_uninitialized
> checks if predicate of variable use overlaps with predicate of undefined control flow path.
> For now, it only checks ssa_var comparing against constant, this can be improved where
> ssa_var compares against another ssa_var with value range info, as described in comment:
>
> +         /* Check value range info of rhs, do following transforms:
> +              flag_var < [min, max]  ->  flag_var < max
> +              flag_var > [min, max]  ->  flag_var > min
> +
> +            We can also transform LE_EXPR/GE_EXPR to LT_EXPR/GT_EXPR:
> +              flag_var <= [min, max] ->  flag_var < [min, max+1]
> +              flag_var >= [min, max] ->  flag_var > [min-1, max]
> +            if no overflow/wrap.  */
>
> This change can avoid some false warning.  Bootstrap and test on x86_64, any comment?

Definitely a good idea - the refactoring makes the patch hard to
follow though.  The
original code seems to pick any (the "first") compare against a constant.  You
return the "first" but maybe from range info that might also be
[-INF,+INF].  It seems
that we'd want to pick the best so eventually sort the predicate chain
so that compares
against constants come first at least?  Not sure if it really makes a
difference but
even currently we could have i < 5, i < 1 so the "better" one later?
It might also make
sense to simply push three predicates for i < j, namely i < j (if ever
useful), i < min(j)
and max(i) < j to avoid repeatedly doing the range computations.

Thanks,
Richard.

> Thanks,
> bin
>
> 2020-01-08  Bin Cheng  <bin.linux@linux.alibaba.com>
>
>  * tree-ssa-uninit.c (find_var_cmp_const): New function.
>  (use_pred_not_overlap_with_undef_path_pred): Call above.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]