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