On Mon, Nov 11, 2013 at 3:45 PM, Ilya Enkovich <enkovich....@gmail.com> wrote:
> 2013/11/11 Richard Biener <richard.guent...@gmail.com>:
>> On Mon, Nov 11, 2013 at 3:00 PM, Ilya Enkovich <enkovich....@gmail.com>
>> wrote:
>>> 2013/11/11 Richard Biener <richard.guent...@gmail.com>:
>>>> On Fri, Nov 8, 2013 at 11:03 AM, Ilya Enkovich <enkovich....@gmail.com>
>>>> wrote:
>>>>> 2013/11/8 Richard Biener <richard.guent...@gmail.com>:
>>>>>> On Thu, Nov 7, 2013 at 7:55 PM, Jeff Law <l...@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?
Ah, ok I wasn't aware of that.
> 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.
Good.
Richard.
> 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
