Re: [PATCH, MPX, 2/X] Pointers Checker [10/25] Calls copy and verification

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2013/11/11 Richard Biener <richard.guenther@gmail.com>:
> On Mon, Nov 11, 2013 at 3:00 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>> 2013/11/11 Richard Biener <richard.guenther@gmail.com>:
>>> On Fri, Nov 8, 2013 at 11:03 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>> 2013/11/8 Richard Biener <richard.guenther@gmail.com>:
>>>>> On Thu, Nov 7, 2013 at 7:55 PM, Jeff Law <law@redhat.com> wrote:
>>>>>> On 11/07/13 04:50, Ilya Enkovich wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is an updated patch version.
>>>>>>
>>>>>> I think this needs to hold until we have a consensus on what the parameter
>>>>>> passing looks like for bounded pointers.
>>>>>
>>>>> I still think the best thing to do on GIMPLE is
>>>>>
>>>>> arg_2 = __builtin_ia32_bnd_arg (arg_1(D));
>>>>> foo (arg_2);
>>>>>
>>>>> that is, make the parameter an implicit pair of {value, bound} where
>>>>> the bound is determined by the value going through a bound association
>>>>> builtin.  No extra explicit argument to the calls so arguments match
>>>>> the fndecl and fntype.  All the complexity is defered to the expander
>>>>> which can trivially lookup bound arguments via the SSA def (I suppose
>>>>> it does that anyway now for getting at the explicit bound argument now).
>>>>>
>>>>> As far as I can see (well, think), all currently passed bound arguments
>>>>> are the return value of such builtin already.
>>>>
>>>> All bounds are result of different builtin calls. Small example:
>>>>
>>>> int *global_p;
>>>> void foo (int *p)
>>>> {
>>>>   int buf[10];
>>>>   bar (p, buf, global_p);
>>>> }
>>>>
>>>>
>>>> It is translated into:
>>>>
>>>>   __bound_tmp.1_7 = __builtin_ia32_bndmk (&buf, 40);
>>>>   __bound_tmp.1_6 = __builtin_ia32_arg_bnd (p_3(D)(ab));
>>>>   global_p.0_2 = global_p;
>>>>   __bound_tmp.1_8 = __builtin_ia32_bndldx (&global_p, global_p.0_2);
>>>>   bar (p_3(D)(ab), __bound_tmp.1_6, &buf, __bound_tmp.1_7,
>>>> global_p.0_2, __bound_tmp.1_8);
>>>>
>>>> Bounds binding via calls as you suggest may be done as following:
>>>>
>>>>   __bound_tmp.1_7 = __builtin_ia32_bndmk (&buf, 40);
>>>>   __bound_tmp.1_6 = __builtin_ia32_arg_bnd (p_3(D)(ab));
>>>>   global_p.0_2 = global_p;
>>>>   __bound_tmp.1_8 = __builtin_ia32_bndldx (&global_p, global_p.0_2);
>>>>   _9 = __builtin_bind_bounds (p_3(D)(ab), __bound_tmp.1_6);
>>>>   _10 = __builtin_bind_bounds (&buf, __bound_tmp.1_7);
>>>>   _11 = __builtin_bind_bounds (global_p.0_2, __bound_tmp.1_8);
>>>>   bar (_9, _10, _11);
>>>>
>>>> Is it close to what you propose?
>>>
>>> Yes.
>>
>> Is there a way to bind bounds with structures in a similar way?
>
> Not to have them easy to lookup in the SSA web.  A long time ago
> I proposed to make SSA aggregates possible, so you could do
>
>  tem_2 = __internal_bind_bounds (aggr(D), __bound_tmp.1_3,
> __bound_tmp.1_4, ...);
>  bar (tem_2);
>
> (originally the SSA aggregates were supposed to make copy-propgagation
> possible using the SSA copy propagator, and of course I needed it for
> the middle-end array work)
>
> Not sure if that will give other people the creeps (expand would
> never expand the "load" from tem_2 but instead handle aggr as
> parameter).  A slight complication is due to alias analysis
> which would be need to taught that bar performs a load of aggr.

It would require bounds loading for aggr before __internal_bind_bounds
anyway.  So, why not to do it in expand?  I just need to mark calls
with a flag (which you've proposed few times already) to let expand
know when it should load bounds.  Having SSA aggregates would be nice
but I suspect it has much higher impact then loading bounds in expand.
 I want to try simpler variant first.

Thanks,
Ilya

>
> Richard.
>
>>  For
>> SSA names I may easily find definition and check if it is a binding
>> builtin call. But for structures it is not possible.  The way I see it
>> to mark all such args as addressable and load required bounds on
>> expand pass.
>>
>> Ilya
>>>
>>> Richard.
>>>
>>>> Ilya
>>>>>
>>>>> Richard.
>>>>>
>>>>>
>>>>>
>>>>>> Jeff