https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
--- Comment #8 from bin cheng <amker at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #7) > On Mon, 15 Jul 2019, amker at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137 > > > > --- Comment #6 from bin cheng <amker at gcc dot gnu.org> --- > > (In reply to Richard Biener from comment #2) > > > > > > and I can very well imagine we're getting confused by find_base_term > > > logic here. > > > > > > There's logic in IVOPTs to not generate IVs based on two different > > > objects but somehow it doesn't trigger here. > > > > Hmm, it's because determine_base_object failed to identify the `base_object` > > for IV because it has non-pointer type: > > IV struct: > > SSA_NAME: _32 > > Type: unsigned long > > Base: (unsigned long) &d + 19600 > > Step: 4 > > Biv: N > > Overflowness wrto loop niter: Overflow > > > > And we have short-circuit in determine_base_object: > > > > static tree > > determine_base_object (tree expr) > > { > > enum tree_code code = TREE_CODE (expr); > > tree base, obj; > > > > /* If this is a pointer casted to any type, we need to determine > > the base object for the pointer; so handle conversions before > > throwing away non-pointer expressions. */ > > if (CONVERT_EXPR_P (expr)) > > return determine_base_object (TREE_OPERAND (expr, 0)); > > > > if (!POINTER_TYPE_P (TREE_TYPE (expr))) > > return NULL_TREE; > > > > The IV is generated from inner loop ivopts as we rewrite using unsigned > > type. > > > > Any suggestion how to fix this? > > I think we need to elide this check and make the following code > more powerful which includes actually handling PLUS/MINUS_EXPR. > There's also ptr + (unsigned)&ptr to be considered for the > POINTER_PLUS_EXPR case - thus we cannot simply only search the > pointer chain. > > Which then leads us into exponential behavior if this is asked > on SCEV results which may have tree sharing, thus we need some > 'visited' machinery. In the end I think we should re-do Will work on a patch. One thing I am unclear about is the ptr + (unsigned)&ptr stuff, when would we have this? Could you provide an example please? > it like I re-did contains_abnormal_ssa_name_p, use > walk_tree_without_duplicates. Btw, what should happen if the > walk discovers two bases are used in the expression? I guess it depends on why there are multiple bases in the first place?
