[PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

[Andrew Pinski]

On Mon, Mar 2, 2020 at 1:40 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Mon, Mar 2, 2020 at 9:07 AM bin.cheng <bin.cheng@linux.alibaba.com> wrote:
> >
> > Hi,
> > This is a simple fix for PR93674.  It adds cand carefully for enumeral type iv_use in
> > case of -fstrict-enums, it also avoids computing, replacing iv_use with the candidate
> > so that no IV of enumeral type is introduced with -fstrict-enums option.
> >
> > Testcase is also added.  Bootstrap and test on x86_64.  Any comment?
>
> I think we should avoid enum-typed (or bool-typed) IVs in general, not just
> with -fstrict-enums.  That said, the ENUMERAL_TYPE checks should be
> !(INTEGER_TYPE || POINTER_TYPE_P) checks.

Maybe even check type_has_mode_precision_p or
TYPE_MIN_VALUE/TYPE_MAX_VALUE have the same as the min/max for that
precision/signedness.

Thanks,
Andrew

>
> +  /* Check if cand can represent values of use for strict enums.  */
> +  else if (TREE_CODE (ctype) == ENUMERAL_TYPE && flag_strict_enums)
> +    {
>
> if we don't have enum-typed IV candidates then the computation should
> be carried out in INTEGER_TYPE and then be converted to enum type.
> So why's this and the may_eliminate_iv hunks necessary?
>
> Richard.
>
> > Thanks,
> > bin
> > 2020-03-02  Bin Cheng  <bin.cheng@linux.alibaba.com>
> >
> >         PR tree-optimization/93674
> >         * tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Add candidate
> >         for enumeral type iv_use converted from other iv.
> >         (get_computation_cost, may_eliminate_iv): Avoid compute, eliminate
> >         iv_use with enumeral type iv_cand in case of -fstrict-enums.
> >
> > gcc/testsuite
> > 2020-03-02  Bin Cheng  <bin.cheng@linux.alibaba.com>
> >
> >         PR tree-optimization/93674
> >         * g++.dg/pr93674.C: New test.