return Bailout("reference to a variable which requires dynamic lookup");

return Bailout("Object literal with complex property");

if (!Smi::IsValid(i)) return Bailout("Non-smi key in array literal");

return Bailout("unsupported const compound assignment");

return Bailout("compound assignment to lookup slot");

return Bailout("invalid lhs in compound assignment");

return Bailout("non-initializer assignment to const");

return Bailout("assignment to const context slot");

if (proxy->IsArguments()) return Bailout("assignment to arguments");

return Bailout("assignment to LOOKUP or const CONTEXT variable");

return Bailout("invalid left-hand side in assignment");

Bailout("arguments access in inlined function");

Bailout("Function.prototype.apply optimization in inlined function");

return Bailout("call to a JavaScript runtime function");

Bailout("delete with global variable");

Bailout("delete with non-global variable");

return Bailout("invalid lhs in count operation");

return Bailout("unsupported count operation with const");

return Bailout("lookup variable in count operation");

return Bailout("Unsupported non-primitive compare");

return Bailout("unsupported declaration");

return Bailout("inlined runtime function: IsNonNegativeSmi");

return Bailout(

return Bailout("inlined runtime function: ClassOf");

return Bailout("inlined runtime function: SetValueOf");

return Bailout("inlined runtime function: RandomHeapNumber");

return Bailout("inlined runtime function: GetFromCache");

return Bailout("inlined runtime function: SwapElements");

return Bailout("inlined runtime function: MathSqrt");

return Bailout("inlined runtime function: IsRegExpEquivalent");

return Bailout("inlined runtime function: FastAsciiArrayJoin");

I was also pleased to learn that my assumption that modern JS engines de-optimize when they see use of "arguments" is no longer true. E.g. uses like fn.apply(this, arguments)which is often used in AOP style function wrapping would be able to run in optimized code. I benchmarked various uses of arguments in this JSPerf testcase. The idea is to have a loop in each test which should be easily optimized but which would take so long to run that the actual usage of "arguments" in the first statement should not influence the benchmark itself. Suggestions how to make this better, appreciated :)

Does anyone know of similar ways to find out about which elements of JS will trigger running in non-optimized mode for other (open source) engines?