On Sep 21, 2010, at 12:57 PM, Maciej Stachowiak wrote:
>
> 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.
In strict mode arguments aren't live, arguments.callee, function.caller and
function.arguments throw for any strict function.
>
> Regards,
> Maciej
>
_______________________________________________
squirrelfish-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
