Bug 122861 - Baseline JIT should use the DFG GetById IC
Summary: Baseline JIT should use the DFG GetById IC
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
Depends on:
Blocks: 121641
  Show dependency treegraph
 
Reported: 2013-10-15 14:03 PDT by Filip Pizlo
Modified: 2013-10-16 18:19 PDT (History)
8 users (show)

See Also:


Attachments
work in progress (102.19 KB, patch)
2013-10-15 14:28 PDT, Filip Pizlo
no flags Details | Formatted Diff | Diff
the patch (102.41 KB, patch)
2013-10-15 17:14 PDT, Filip Pizlo
oliver: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff
patch for ews (103.34 KB, patch)
2013-10-15 18:45 PDT, Filip Pizlo
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2013-10-15 14:03:39 PDT
Patch forthcoming.
Comment 1 Filip Pizlo 2013-10-15 14:28:44 PDT
Created attachment 214299 [details]
work in progress

Almost done.  Still testing it.
Comment 2 Filip Pizlo 2013-10-15 17:14:01 PDT
Created attachment 214323 [details]
the patch
Comment 3 Oliver Hunt 2013-10-15 17:35:43 PDT
Comment on attachment 214323 [details]
the patch

View in context: https://bugs.webkit.org/attachment.cgi?id=214323&action=review

wow, that is a lot of red

> Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:473
>      BEGIN_UNINTERRUPTED_SEQUENCE(sequenceGetByIdHotPath);

Remove this -- you've removed the corresponding end.  Maybe worth just having an initial patch remove the *_UNINTERRUPTED_* macros -- assuming the patchable jump/label logic is handling everything correctly we no long reed to worry about inline constant pools breaking repatching.
Comment 4 Build Bot 2013-10-15 17:55:52 PDT
Comment on attachment 214323 [details]
the patch

Attachment 214323 [details] did not pass win-ews (win):
Output: http://webkit-queues.appspot.com/results/3744094
Comment 5 Filip Pizlo 2013-10-15 18:38:22 PDT
(In reply to comment #3)
> (From update of attachment 214323 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=214323&action=review
> 
> wow, that is a lot of red
> 
> > Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:473
> >      BEGIN_UNINTERRUPTED_SEQUENCE(sequenceGetByIdHotPath);
> 
> Remove this -- you've removed the corresponding end.  Maybe worth just having an initial patch remove the *_UNINTERRUPTED_* macros -- assuming the patchable jump/label logic is handling everything correctly we no long reed to worry about inline constant pools breaking repatching.

And, I don't think we use inline constant pools on any of the platforms we care about...
Comment 6 Filip Pizlo 2013-10-15 18:40:04 PDT
(In reply to comment #4)
> (From update of attachment 214323 [details])
> Attachment 214323 [details] did not pass win-ews (win):
> Output: http://webkit-queues.appspot.com/results/3744094

Oops, those look like easy 32-bit fixes.
Comment 7 Filip Pizlo 2013-10-15 18:41:17 PDT
(In reply to comment #3)
> (From update of attachment 214323 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=214323&action=review
> 
> wow, that is a lot of red
> 
> > Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:473
> >      BEGIN_UNINTERRUPTED_SEQUENCE(sequenceGetByIdHotPath);
> 
> Remove this -- you've removed the corresponding end.  Maybe worth just having an initial patch remove the *_UNINTERRUPTED_* macros -- assuming the patchable jump/label logic is handling everything correctly we no long reed to worry about inline constant pools breaking repatching.

I think after this lands, I'll do a couple of cycles of looking for stupidities to remove, including those macros.
Comment 8 Filip Pizlo 2013-10-15 18:45:22 PDT
Created attachment 214328 [details]
patch for ews
Comment 9 Filip Pizlo 2013-10-15 19:35:47 PDT
Landed in http://trac.webkit.org/changeset/157480
Comment 10 Roger Fong 2013-10-16 12:08:07 PDT
Hi, I think the following failure started occurring on Windows after this patch:
http://build.webkit.org/results/Apple%20Win%207%20Release%20(Tests)/r157480%20(39294)/js/dictionary-prototype-caching-pretty-diff.html

does this look related to you? thx
Comment 11 Filip Pizlo 2013-10-16 13:04:01 PDT
(In reply to comment #10)
> Hi, I think the following failure started occurring on Windows after this patch:
> http://build.webkit.org/results/Apple%20Win%207%20Release%20(Tests)/r157480%20(39294)/js/dictionary-prototype-caching-pretty-diff.html
> 
> does this look related to you? thx

See https://bugs.webkit.org/show_bug.cgi?id=122902
Comment 12 Roger Fong 2013-10-16 18:19:59 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > Hi, I think the following failure started occurring on Windows after this patch:
> > http://build.webkit.org/results/Apple%20Win%207%20Release%20(Tests)/r157480%20(39294)/js/dictionary-prototype-caching-pretty-diff.html
> > 
> > does this look related to you? thx
> 
> See https://bugs.webkit.org/show_bug.cgi?id=122902

Hmm this is a layout test failure and not a jscore test failure, still broken. I'll take a closer look and let you know what i find.