RESOLVED FIXED 226146
[JSC] Add JIT ICs for `#x in obj` feature
https://bugs.webkit.org/show_bug.cgi?id=226146
Summary [JSC] Add JIT ICs for `#x in obj` feature
Ross Kirsling
Reported 2021-05-22 15:42:12 PDT
This is needed in order to ship.
Attachments
Patch (64.08 KB, patch)
2021-06-15 16:32 PDT, Ross Kirsling
no flags
Test patch for MIPS EWS (62.63 KB, patch)
2021-06-15 21:03 PDT, Ross Kirsling
no flags
Test patch for MIPS EWS (62.61 KB, patch)
2021-06-15 22:38 PDT, Ross Kirsling
no flags
Baseline-only patch for MIPS EWS debugging (36.05 KB, patch)
2021-06-17 12:29 PDT, Ross Kirsling
ews-feeder: commit-queue-
Baseline-only patch for MIPS EWS debugging (38.70 KB, patch)
2021-06-17 12:56 PDT, Ross Kirsling
no flags
Baseline-only patch for MIPS EWS debugging (38.70 KB, patch)
2021-06-17 13:03 PDT, Ross Kirsling
no flags
Patch (66.62 KB, patch)
2021-06-17 16:18 PDT, Ross Kirsling
no flags
Radar WebKit Bug Importer
Comment 1 2021-05-29 15:43:16 PDT
Ross Kirsling
Comment 2 2021-06-15 16:32:48 PDT
Ross Kirsling
Comment 3 2021-06-15 21:03:38 PDT Comment hidden (obsolete)
Ross Kirsling
Comment 4 2021-06-15 22:38:18 PDT
Created attachment 431520 [details] Test patch for MIPS EWS
Ross Kirsling
Comment 5 2021-06-17 12:29:44 PDT Comment hidden (obsolete)
Ross Kirsling
Comment 6 2021-06-17 12:56:23 PDT Comment hidden (obsolete)
Ross Kirsling
Comment 7 2021-06-17 13:03:32 PDT
Created attachment 431708 [details] Baseline-only patch for MIPS EWS debugging
Ross Kirsling
Comment 8 2021-06-17 16:18:57 PDT
Created attachment 431734 [details] Patch Rebasing.
Ross Kirsling
Comment 9 2021-06-17 18:46:31 PDT
Well, I dunno what was up with MIPS before, but we're green now!
Saam Barati
Comment 10 2021-06-21 18:51:26 PDT
Comment on attachment 431734 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=431734&action=review Nice. r=me > Source/JavaScriptCore/jit/Repatch.cpp:1083 > + InlineCacheAction action = actionForCell(vm, base); Do we care about Structure::propertyAccessesAreCacheable for has private brand semantics? I also wonder if we care about uncacheable dictionary. It looks like setPrivateBrand will always transition. Not sure if we really care about those cases or not. My hunch is: we don't care about Structure::propertyAccessesAreCacheable, but we probably shouldn't rely on UncacheableDictionary not transitioning. That said, I don't see in our current implementation how we could do it without always transitioning given that we rely on the m_parentBrand pointer.
Saam Barati
Comment 11 2021-06-21 18:54:01 PDT
(In reply to Saam Barati from comment #10) > Comment on attachment 431734 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=431734&action=review > > Nice. r=me > > > Source/JavaScriptCore/jit/Repatch.cpp:1083 > > + InlineCacheAction action = actionForCell(vm, base); > > Do we care about Structure::propertyAccessesAreCacheable for has private > brand semantics? > > I also wonder if we care about uncacheable dictionary. It looks like > setPrivateBrand will always transition. > > Not sure if we really care about those cases or not. > > My hunch is: we don't care about Structure::propertyAccessesAreCacheable, > but we probably shouldn't rely on UncacheableDictionary not transitioning. > That said, I don't see in our current implementation how we could do it > without always transitioning given that we rely on the m_parentBrand pointer. When I say "we don't care", I mean in terms of correctness: bool propertyAccessesAreCacheable() { return dictionaryKind() != UncachedDictionaryKind && prototypeQueriesAreCacheable() && !(typeInfo().getOwnPropertySlotIsImpure() && !typeInfo().newImpurePropertyFiresWatchpoints()); } I don't think "typeInfo().getOwnPropertySlotIsImpure" changes the semantics here. I don't think prototypeQueriesAreCacheable() changes the semantics here either.
Ross Kirsling
Comment 12 2021-06-21 23:13:28 PDT
Comment on attachment 431734 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=431734&action=review >>> Source/JavaScriptCore/jit/Repatch.cpp:1083 >>> + InlineCacheAction action = actionForCell(vm, base); >> >> Do we care about Structure::propertyAccessesAreCacheable for has private brand semantics? >> >> I also wonder if we care about uncacheable dictionary. It looks like setPrivateBrand will always transition. >> >> Not sure if we really care about those cases or not. >> >> My hunch is: we don't care about Structure::propertyAccessesAreCacheable, but we probably shouldn't rely on UncacheableDictionary not transitioning. That said, I don't see in our current implementation how we could do it without always transitioning given that we rely on the m_parentBrand pointer. > > When I say "we don't care", I mean in terms of correctness: > > bool propertyAccessesAreCacheable() > { > return dictionaryKind() != UncachedDictionaryKind > && prototypeQueriesAreCacheable() > && !(typeInfo().getOwnPropertySlotIsImpure() && !typeInfo().newImpurePropertyFiresWatchpoints()); > } > > > I don't think "typeInfo().getOwnPropertySlotIsImpure" changes the semantics here. > > I don't think prototypeQueriesAreCacheable() changes the semantics here either. Hmm, good question(s). tryCacheHasPrivateBrand is largely a mimicry of tryCacheCheckPrivateBrand except that it creates AccessCase::{InHit, InMiss}, so I'm kind of relying on the other having been written correctly. Happy to do follow-up work here if needed.
EWS
Comment 13 2021-06-21 23:41:21 PDT
Committed r279105 (239022@main): <https://commits.webkit.org/239022@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 431734 [details].
Note You need to log in before you can comment on or make changes to this bug.