Re: [CHKP] Support returned bounds in thunks expand

[Ilya Enkovich <enkovich.gnu@gmail.com>]

2015-04-02 23:55 GMT+03:00 Jan Hubicka <hubicka@ucw.cz>:
>> Ping
>>
>> 2015-03-10 13:12 GMT+03:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
>> > Hi,
>> >
>> > Currentl we loose returned bounds when functions are merged.  This patch fixes it by adding returne bounds support for cgraph_node::expand_thunk.  Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for trunk?
>> > 2015-03-06  Ilya Enkovich  <ilya.enkovich@intel.com>
>> >
>> >         * cgraphunit.c (cgraph_node::expand_thunk): Build returned
>> >         bounds for instrumented functions.
>
> I think if the extra bultin call is needed here, the same andling needs to be
> added to ipa-split.  We really ought to unify that code - it is surprisingly
> difficult to produce a wrapper call these days.

Yep, there is such code in place. It is done by
insert_bndret_call_after. You are right, I should use the same
interface for both these cases.

>> > +         if (instrumentation_clone
>> > +             && !DECL_BY_REFERENCE (resdecl)
>> > +             && restmp
>> > +             && BOUNDED_P (restmp))
>> > +           {
>> > +             tree fn = targetm.builtin_chkp_function (BUILT_IN_CHKP_BNDRET);
>> > +             gcall *retbnd = gimple_build_call (fn, 1, restmp);
>> > +
>> > +             resbnd = create_tmp_reg (pointer_bounds_type_node, "retbnd");
>> > +             gimple_call_set_lhs (retbnd, resbnd);
>> > +
>> > +             gsi_insert_after (&bsi, retbnd, GSI_NEW_STMT);
>> > +             create_edge (get_create (fn), retbnd, callees->count, callees->frequency);
>> > +           }
>
> I am not sure why we need to check here:  Originaly we have two bounded functions, A and B.
> We turn function B to a wrapper of function A. If callers of bounded functions need
> to call a builtin, I would expect all callers of B to do it already, so I would expect
> that wrapper is safe here?

The problem with instrumented call is that instrumented function
returns two values and call lhs gets only the first one. Thus we
generate bndret call to get the second one to build own return with
two values.

>
> Or do we mix instrumented and non-instrumented versions somehow?
>
> Addding code handling return value is going to turn the call to non-tailcall, so you probably
> want to drop the tailcall flag, too.

No, function still return what the last call return, thus may keep tailcall.

Thanks,
Ilya

>
> Honza