Hello Kugan,
sorry, I have lost track of this patch and re-discovered it only now.
On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:
> Hi,
>
> On 24/11/16 19:48, Richard Biener wrote:
> > On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor <mjam...@suse.cz> wrote:
> > > Hi,
> > >
> > > On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:
> > > > Hi,
> > > >
> > > > I was relying on ipa_get_callee_param_type to get type of parameter and
> > > > then
> > > > convert arguments to this type while computing jump functions. However,
> > > > in
> > > > cases like shown in PR78365, ipa_get_callee_param_type, instead of
> > > > giving
> > > > up, would return the wrong type.
> > >
> > > At what stage does this happen? During analysis
> > > (ipa_compute_jump_functions_for_edge) or at WPA
> > > (propagate_constants_accross_call)? Both?
> >
> > Hmm, where does jump function compute require the callee type?
> > In my view the jump function should record
> >
> > (expected-incoming-type) arg [OP X]
> >
> > for each call argument in its body. Thus required conversions are
> > done at WPA propagation time.
> >
> > > > I think the current uses of
> > > > ipa_get_callee_param_type are fine with this.
> > > >
> > > > Attached patch now uses callee's DECL_ARGUMENTS to get the type. If it
> > > > cannot be found, then I would give up and set the jump function to
> > > > varying.
> > >
> > > But DECL_ARGUMENTS is not available at WPA stage with LTO so your
> > > patch would make our IPA layer to optimize less with LTO. This was
> > > the reason to go through the hoops of TYPE_ARG_TYPES in the first
> > > place.
> > >
> > > If TYPE_ARG_TYPES cannot be trusted, then I'm afraid we are back to
> > > square one and indeed need to put the correct type in jump functions.
> >
> > If DECL_ARGUMENTS is not available at WPA stage then I see no other
> > way than to put the types on the jump functions.
>
> 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?
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 2ec671f..3d50041 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge
> *cs, int idx, ipa_jump_func *j
> static bool
> propagate_vr_accross_jump_function (cgraph_edge *cs,
> ipa_jump_func *jfunc,
> - struct ipcp_param_lattices *dest_plats,
> - tree param_type)
> + struct ipcp_param_lattices *dest_plats)
> {
> struct ipcp_param_lattices *src_lats;
> ipcp_vr_lattice *dest_lat = &dest_plats->m_value_range;
> + tree param_type = jfunc->param_type;
>
> if (dest_lat->bottom_p ())
> return false;
> @@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
> tree val = ipa_get_jf_constant (jfunc);
> if (TREE_CODE (val) == INTEGER_CST)
> {
> + val = fold_convert (param_type, val);
> if (TREE_OVERFLOW_P (val))
> val = drop_tree_overflow (val);
> - val = fold_convert (param_type, val);
> jfunc->vr_known = true;
> jfunc->m_vr.type = VR_RANGE;
> jfunc->m_vr.min = val;
> @@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge
> *cs)
> {
> struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
> struct ipcp_param_lattices *dest_plats;
> - tree param_type = ipa_get_callee_param_type (cs, i);
>
> dest_plats = ipa_get_parm_lattices (callee_info, i);
> if (availability == AVAIL_INTERPOSABLE)
> @@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge
> *cs)
> dest_plats);
> if (opt_for_fn (callee->decl, flag_ipa_vrp))
> ret |= propagate_vr_accross_jump_function (cs,
> - jump_func, dest_plats,
> - param_type);
> + jump_func, dest_plats);
> else
> ret |= dest_plats->m_value_range.set_to_bottom ();
> }
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 90c19fc..235531b 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -1651,14 +1651,24 @@ determine_locally_known_aggregate_parts (gcall *call,
> tree arg,
> /* Return the Ith param type of callee associated with call graph
> edge E. */
>
> -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).
>
> for (n = 0; n < i; n++)
> {
> @@ -1670,15 +1680,6 @@ ipa_get_callee_param_type (struct cgraph_edge *e, int
> i)
> return TREE_VALUE (t);
> if (!e->callee)
> return NULL;
> - t = DECL_ARGUMENTS (e->callee->decl);
> - for (n = 0; n < i; n++)
> - {
> - if (!t)
> - return NULL;
> - t = TREE_CHAIN (t);
> - }
> - if (t)
> - return TREE_TYPE (t);
> return NULL;
> }
>
> @@ -1724,6 +1725,7 @@ ipa_compute_jump_functions_for_edge (struct
> ipa_func_body_info *fbi,
> useful_context = true;
> }
>
> + jfunc->param_type = param_type;
> if (POINTER_TYPE_P (TREE_TYPE (arg)))
> {
> bool addr_nonzero = false;
> @@ -4709,6 +4711,7 @@ ipa_write_jump_function (struct output_block *ob,
> int i, count;
>
> streamer_write_uhwi (ob, jump_func->type);
> + stream_write_tree (ob, jump_func->param_type, true);
> switch (jump_func->type)
> {
> case IPA_JF_UNKNOWN:
> @@ -4792,6 +4795,7 @@ ipa_read_jump_function (struct lto_input_block *ib,
> int i, count;
>
> jftype = (enum jump_func_type) streamer_read_uhwi (ib);
> + jump_func->param_type = stream_read_tree (ib, data_in);
> switch (jftype)
> {
> case IPA_JF_UNKNOWN:
> diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> index 0e75cf4..8dcce99 100644
> --- a/gcc/ipa-prop.h
> +++ b/gcc/ipa-prop.h
> @@ -180,6 +180,7 @@ struct GTY (()) ipa_jump_func
>
> /* Information about value range. */
> bool vr_known;
> + tree param_type;
Please add a comment describing what this is.
Otherwise, the intent looks fine to me.
Thanks!
Martin
