This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, Pointer Bounds Checker 27/x] Strlen
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 31 Jul 2014 14:07:49 +0400
- Subject: Re: [PATCH, Pointer Bounds Checker 27/x] Strlen
- Authentication-results: sourceware.org; auth=none
- References: <20140611081414 dot GA17894 at msticlxl57 dot ims dot intel dot com> <20140611082214 dot GL19001 at tucnak dot redhat dot com>
2014-06-11 12:22 GMT+04:00 Jakub Jelinek <email@example.com>:
> On Wed, Jun 11, 2014 at 12:14:14PM +0400, Ilya Enkovich wrote:
>> This patch adds instrumented code support for strlen optimization.
>> Bootstrapped and tested on linux-x86_64.
>> Does it look OK?
> Ugh, this looks terribly ugly. So you are changing the meaning of arguments
> of every single builtin that has pointer arguments, so all spots that
> work with those builtins have to take into account
> gimple_call_with_bounds_p and do something different?
> That is very error prone and maintainance nightmare.
I've tried an approach with internal functions usage as you suggested
Shortly about used scheme:
- only a selected set of builtin functions is instrumented
- during instrumentation builtin call is replaced with internal function call
I tried to implement it and faced few issues:
1. On expand pass we need to expand all those internal function and
since they should be expanded as regular instrumented calls, I need to
create a CALL_EXPR tree for that. I have nothing to use as fndecl for
this call except the same instrumented builtin fndecl I use right now.
Therefore the problem of instrumented call with the same builtin
function code would still exist during expand pass.
2. Some builtins actually may have body. If I instrument such call and
replace it with internal call then I loose a possibility to inline it.
If I do not replace it with internal call then I have to make an
instrumented call and again I have to create and use instrumented
builtin fndecl having the same situation I have now but this time only
until call is inlined.
3. Usage of internal functions means we cannot support whole program
instrumentation (or we have to declare internal function for each
builtin) which may appear a very useful scheme with reduced memory and
Now I want to try another scheme. I want to change enum
built_in_function so that each builtin code has a paired code to be
used for instrumented version. I'm not going to actually declare
additional builtins for users, I just want to obtain special function
codes to be used for instrumented builtins and thus to not make
current code handling builtins to work with instrumented calls.