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. + /* 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.