On Fri, Dec 9, 2016 at 11:51 AM, Martin Jambor <mjam...@suse.cz> wrote: > Hi, > > On Fri, Dec 09, 2016 at 03:36:44PM +1100, kugan wrote: >> On 07/12/16 21:08, Martin Jambor wrote: >> > On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote: >> > >> > ... >> > >> > > Here is a patch that does this. To fox PR78365, in >> > > ipa_get_callee_param_type, I am now checking DECL_ARGUMENTS first. I lto >> > > bootstrapped and regression tested on x86_64-linux-gnu and ppc64le-linux >> > > with no new regressions. I will build Firefox and measure the memory >> > > usage >> > > as Honza suggested based on the feedback. >> > > >> > >> > So, do you have any numbers? >> I will do it. How do you measure the gcc's memory usage while building >> Firefox. I saw Honza's LTO blog talks about using vmstat result. Any tips >> please? > > I asked Martin Liska how he does it and he replied with: > > Steps: > > 1) clone git repository: https://github.com/marxin/script-misc > > 2) Run command that does an LTO linking > > 3) ./system_top.py > /tmp/log > Run that in a separate terminal, terminate the script after the LTO linking > finishes. > > 4) ./vmstat_parser.py /tmp/log > Plot the collected data. > > so try that :-) As far as I know, it uses vmstat. Or maybe Honza > has some other method. > > >> > ... >> > >> > > -tree >> > > +static tree >> > > ipa_get_callee_param_type (struct cgraph_edge *e, int i) >> > > { >> > > int n; >> > > + tree t = e->callee ? DECL_ARGUMENTS (e->callee->decl) : NULL_TREE; >> > > + if (t) >> > > + for (n = 0; n < i; n++) >> > > + { >> > > + if (!t) >> > > + return NULL; >> > > + t = TREE_CHAIN (t); >> > > + } >> > > + if (t) >> > > + return TREE_TYPE (t); >> > > tree type = (e->callee >> > > ? TREE_TYPE (e->callee->decl) >> > > : gimple_call_fntype (e->call_stmt)); >> > > - tree t = TYPE_ARG_TYPES (type); >> > > + t = TYPE_ARG_TYPES (type); >> > >> > If TYPE_ARG_TYPES is inherently unreliable then I am afraid you must >> > not fallback on it but rather return NULL if cs->callee is not >> > available and adjust the caller to give up in that case. >> > >> > (I have checked both testcases that we hope to fix with types in jump >> > functions and the gimple_call_fntype is the same as >> > TREE_TYPE(e->callee->decl) so that does not help either). >> >> Do you like the attached patch where I have removed it. >> > > I am fine with the new patch but you'll need an approval from Honza > or Richi. > > I find it a bit saddening that we cannot really rely on > gimple_call_fntype but at least I do not see any other way.
The patch looks somewhat backward. It populates the param type from the callee but the only thing we really know is the _originating_ type from the callers DECL_ARGUMENTS (if the JF is based on a parameter which is the only case where we do not know the type of the actual value statically -- we only know the type we expect). So the type would be present only on IPA_JF_PASS_THROUGH JFs (? does that also cover modified params?). At propagation time when applying the jump-function we have to make sure to first convert the actual parameter value to that expected type (or drop to BOTTOM if we can't do that conversion due to excess mismatches). Richard. > Thanks, > > Martin
