2013/11/25 Jeff Law <l...@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 >
