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