This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, MPX, 2/X] Pointers Checker [14/25] Function splitting


2013/11/26 Ilya Enkovich <enkovich.gnu@gmail.com>:
> 2013/11/25 Jeff Law <law@redhat.com>:
>> On 11/25/13 04:12, Ilya Enkovich wrote:
>>>
>>>
>>> I'll prepare a patch to remove committed patches.  But the first part
>>> of series added new ISA extension support.  It is independent from the
>>> checker.  Should it be OK to keep ISA in trunk?
>>
>> I think this can/should reasonably be Uros's call.
>>
>> I'm sorry we didn't get this moved far enough to make it into GCC 4.9; if I
>> had thought we were going run into these issues I wouldn't have suggested
>> you check in the preparatory patches only to have to back them out later.
>
> I also though we could make it go into 4.9.  And taking into account
> encountered problem I think a short time-out to reconsider some design
> elements would be useful.
>
> My next steps in bounds checker improvement include better support for
> optimization passes and generic target support, which would not
> require Intel MPX on hardware to use it.  One of the way is to keep
> going with the current model.  It has some problems but proved to
> work. The main problems are:
>   - Hidden data flow to pass bounds into functions.  We have implicit
> data flow for calls from bind_bounds call in caller and arg_bounds
> call in callee.  Optimization passes do not know about this flow and
> thus may easily corrupt it (especially IPA passes).
>   - Wrapped values.  All call arguments are wrapped by bind_bounds
> calls.  It prevents from some optimizations.  E.g. we cannot propagate
> null pointer value into callee if call is instrumented.
>
> Positive points here:
>   - we do not affect basic infrastructure significantly
>   - initial checker implementation does not require enabling optimization passes
>   - it is possible to enable optimization passes for better work with
> instrumented code; it may be done incrementally
>   - it is implemented and works including some optimizations enabling
>
> The other way I see is to try to make all current optimizations work
> correctly with bounds by making changes in the way we instrument the
> code.  If the main problem is usage of bind_bounds and arg_bounds,
> then we may try to avoid their usage.  The obvious way to do it is to
> use regular arg passing mechanism using call args and params in
> function decls.  The basic idea is to not modify function during
> instrumentation, but create a new one.  We may either keep the
> original version of the function (e.g. for inline into
> non-instrumented callers) or just leave it's declaration to be used
> for non-instrumented calls.
>
> Thus, all functions may result in two nodes in cgraph.  One for
> non-instrumented version and one for instrumented version.  Function
> declaration of the instrumented function would have all bounds in it's
> param list and instrumented call would have all bounds in it's args
> list accordingly.
>
> Advantage of this approach:
>   - It would decrease number of cases when bounds flow is damaged
>   - It would allow to avoid (or at least decrease) modifications in
> IPA passes to handle bounds correctly
>   - It would allow to unbind bounds from pointers and perform IPA
> optimizations for bound values (e.g. if we do not know pointer value
> but know pointer is unchecked, we may propagate it's bounds value into
> callee using existing propagation optimization)
>
> Surely some doubts also exist:
>   - We have two declarations for actually the same function
>   - Most probably need some changes in PARAM_DECLs to bind bounds
> params with pointer params
>   - If we Most probably need some modifications in passes which
> generate new function decls (e.g. propagation or splitting) to
> generate decl with correctly declared bounds

Accidentally sent the letter before finished it :/

But seems I wrote the most of I wanted to.  I know this scheme
description with double function declarations is very basic but I
would like to get your opinion before diving deeper.  Probably current
scheme is not so bad and we should leave basic things as it is?

Thanks,
Ilya

>
>>
>> Jeff
>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]