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/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

>
> Jeff
>


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