On Mon, Mar 2, 2020 at 1:40 AM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Mon, Mar 2, 2020 at 9:07 AM bin.cheng <bin.ch...@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.ch...@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.ch...@linux.alibaba.com>
> >
> > PR tree-optimization/93674
> > * g++.dg/pr93674.C: New test.
