|Summary:||JSC profiler should not count executions of op_call_put_result because doing so changes DFG codegen|
|Product:||WebKit||Reporter:||Filip Pizlo <fpizlo>|
|Severity:||Normal||CC:||barraclough, ggaren, mark.lam, mhahnenberg, msaboff, oliver, sam|
|Version:||528+ (Nightly build)|
Description Filip Pizlo 2012-12-05 01:46:58 PST
op_call_put_result is the return target for inlining. Imagine you have a function that has a jump target immediately following an inlined call, and the inlined call itself has an empty basic block contain just the return statement at its tail. The DFG has the ability to merge the empty basic block at the end of the inlinee with the new basic block created just after the call in the inliner. But, placing a CountExecution node at the return point of the call breaks this optimization, and can have unforeseen impact on codegen. This breaks the main principle of the profiler: to be able to tell us profiling data without affecting codegen. (It may affect performance but the disassembly that you see will be faithful.) The best approach to fixing this is to avoid profiling instructions like op_call_put_result that have this kind of behavior. Doing so will not take away much from the profiler, since usually the counts for op_call_put_result itself are not interesting.