This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Using function clones for Pointer Bounds Checker
- From: Jeff Law <law at redhat dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, "Zamyatin, Igor" <igor dot zamyatin at intel dot com>
- Date: Mon, 12 May 2014 15:20:09 -0600
- Subject: Re: [RFC] Using function clones for Pointer Bounds Checker
- Authentication-results: sourceware.org; auth=none
- References: <CAMbmDYaxC0tZim+AysTLrqak=nX6RmEZQr1QDPU+NG6BYfoE-g at mail dot gmail dot com>
On 01/14/14 02:15, Ilya Enkovich wrote:
Sorry for the delayed reply, when you sent this message I was ignoring
anything that wasn't an open issue for GCC 4.9 -- it all gets thrown
into a massive queue of things to come back to once stage1 reopens.
I've been working for some time on the prototype of the Pointer Bounds
Checker which uses function clones for instrumentation
several experiments with this approach I want to share my results and
ask for some feedback to make a decision about the future steps.
So I really like the idea of trying to use function clones to simplify
some of the details of implementing MPX support.
Clones approach does not use special built-in function calls to
associate bounds with call arguments and input parameters. Each
function which should be instrumented gets an additional version and
only this special version will be instrumented.
I like this.
So from a linking standpoint, presumably you have to mangle the
instrumented caller/callee in some manner. Right? Or are you
dynamically dispatching somehow?
This new version gets
additional bound arguments to express input bounds. When function call
is instrumented, it is redirected to instrumented version and all
bounds are passed as explicit call arguments. Thus we have explicit
pointer bounds flow similar to regular function parameters. It should
allow to avoid changes in optimization, avoid miss-optimizations,
allow existing IPA optimizations to work with bound args (e.g.
propagate constant bounds value and remove checks in called function).
Jan is going to be the best person to discuss these issues with you.
He's the architect behind most of the IPA bits we've got right now.
1. Nodes reachability. Instrumented version is actually always
reachable when original function is reachable because it is always
emitted instead of the original. Thus I had to fix reachability
analysis to achieve it. Another similar problem is check whether node
can be removed after inline when inlining instrumented function. Not
hard to fix but probably other similar problems exist.
In general I feel that having special function version for
instrumentation has a better potential, should lead to less intrusive
changes in the compiler and better code quality.
Agreed. It seems *much* cleaner.