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?
