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

[Martin Jambor <mjambor@suse.cz>]

Hi,

On Fri, Aug 30 2019, Feng Xue OS wrote:
>> (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.

I was merely suggesting a better comment describing the function you are
introducing.

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

Thinking about it a bit more, I think you simply do not want to ever
push the extra VIEW_CONVERT_EXPR to the vector and in
evaluate_conditions_for_known_args always do a fold_convert to the
desired type (similarly like we do today).

Thanks,

Martin

>
>> 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