Consider the following code: function foo() { var o = {}; o.length = 5; for (var i = 0; i < o.length; ++i) o[i] = i; } Currently, array profiling will always say that 'o' is NonArrayWithArrayStorage, even though on the first iteration it's a NonArray (as in it has no array storage). We could catch this corner case in one of two ways: (1) OSR exit profiling or (2) more precise baseline profiling. I prefer (2) because we usually only like to rely on (1) in pathological cases. The above does not feel like a pathological case - it seems rather sensible to write a program that has a loop, where the first iteration of that loop does special things. Of course, we could also kill off this pathology, at least in most cases, by relying on loop peeling. But for now, I think having a more precise array profiler just feels like a nicer solution
Created attachment 164328 [details] the patch
Comment on attachment 164328 [details] the patch Attachment 164328 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/13873232
Created attachment 164330 [details] the patch Fix non-DFG builds.
Landed in http://trac.webkit.org/changeset/128790
(In reply to comment #4) > Landed in http://trac.webkit.org/changeset/128790 It broke the Qt ARM build - https://bugs.webkit.org/show_bug.cgi?id=96968 Could you check it, please?
(In reply to comment #5) > (In reply to comment #4) > > Landed in http://trac.webkit.org/changeset/128790 > > It broke the Qt ARM build - https://bugs.webkit.org/show_bug.cgi?id=96968 > > Could you check it, please? It broke your build because I introduced new assembler functionality. It's up to you guys to implement assembler functionality on your platforms.