On Mon, Mar 2, 2020 at 6:14 PM Andrew Pinski <pins...@gmail.com> wrote:
>
> 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.
Indeed we don't want non-mode precision INTEGER_TYPE IVs either. I wouldn't
check TYPE_MIN/MAX_VALUE here though.
Richard.
> 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.
