On Sep 21, 2010, at 11:37 AM, Holger Freyther wrote:
> On 09/22/2010 02:09 AM, Oliver Hunt wrote:
>
>>
>> In the general case this would require being able to convert from inlined
>> code to a 'correct' call stack at some arbitrary point
>
> argh, I had hoped that such things would be only necessary when we have a
> debugger attached. This mean besides what maciej had said, we will need to
> remember that this range of instructions belongs to a inlined call and be able
> to generate the virtual call record.
>
> Can one write to arguments, callee and such?
arguments can be shadowed or individual arguments can be modified. You can
statically detect when a function might use "arguments" and just avoid inlining
it; the big problems are arguments.caller and func.arguments, since those can
be done by functions called by the inlined function, so it's hard (maybe
impossible) to statically prove they won't happen.
There is a subset of functions that you can prove makes no calls, so in that
case, inlining would be safe without excessive magic. But this would exclude
property access for instance, since getters and setters can turn any property
access into a call. So only functions that stick to simple arithmetic could be
inlined.
>
> I wonder (and will try to measure based on sunspider and other test content)
> how many functions occur like function f(x) { return x +2; } or even fully
> constant. Is there any classification of the complexity of functions at parse
> time?
I wonder how ES5 strict mode affects the challenge of doing inlining correctly.
Regards,
Maciej
_______________________________________________
squirrelfish-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
