This is the mail archive of the 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, Pointer Bounds Checker 27/x] Strlen

2014-06-11 12:22 GMT+04:00 Jakub Jelinek <>:
> 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.
>         Jakub

Hi Jakub,

I've tried an approach with internal functions usage as you suggested
on Cauldron.

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
performance penalties.

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.


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