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
