Re: [PATCH] Generalized predicate/condition for parameter reference in IPA (PR ipa/91088)

[Feng Xue OS <fxue@os.amperecomputing.com>]

> (It's a bad idea to make ChangeLog entries part of the patch, it won't
> apply to anyone, not even to you nowadays. )
Got it. Will not include this kind of info in later patches.

> I understand describing these things is difficult, but flatten is
> strange way to describe what the function does.  What about somthing
> like the following?
> 
> Analyze EXPR if it represents a series of simple operations performed on
> a function parameter and return true if so.  FBI, STMT, INDEX_P, SIZE_P
> and AGGPOS have the same meaning like in
> unmodified_parm_or_parm_agg_item.  Operations on the parameter are
> recorded to PARAM_OPS_P if it is not NULL.
Operations should be recorded in some place, and this is why PARAM_OPS_P
is used. Not quite understand this point.

>> +           /* Find use of parameter, add a convert operation to describe
>> +              result type, which may not be same as parameter type.  */
>> +           eval_op.val_is_rhs = false;
>> +           eval_op.val = NULL_TREE;
>> +           eval_op.code = VIEW_CONVERT_EXPR;
>> +           eval_op.type = TREE_TYPE (expr);
>> +
>> +           vec_safe_insert (*param_ops_p, 0, eval_op);

> If we get here in the first iteration of the loop, could we not insert
> anything into the vector and handle such cases in
> evaluate_conditions_for_known_args like we do today (well, with
> fold_convert might be better)?  It could save quite some memory and it
> is important to try keep the memory footprint down in IPA summaries.
Here is a little trick to make code of folding in evaluate_conditions_for_known_args ()
be simple. It does consume some memory for most cases. Will consider other way
and remove this.

> Also, I think you want a parameter to limit the maximum length of
> param_ops_p, at some point someone will come with some crazy
> machine-generated code that will create huge vectors.
Yes. Exactly.

Thanks,

Martin