[Webkit-unassigned] [Bug 132057] Backtracking with current matching element support for Child fragment.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Apr 23 10:25:10 PDT 2014
https://bugs.webkit.org/show_bug.cgi?id=132057
--- Comment #12 from Yusuke Suzuki <utatane.tea at gmail.com> 2014-04-23 10:25:31 PST ---
(From update of attachment 229991)
View in context: https://bugs.webkit.org/attachment.cgi?id=229991&action=review
> Source/WebCore/cssjit/SelectorCompiler.cpp:124
> + , heightFromDescendant(0)
We calculate backtracking start height from closest descendant combinator.
> Source/WebCore/cssjit/SelectorCompiler.cpp:196
> + void generateElementMatching(Assembler::JumpList& tagNameMatchFailureCases, Assembler::JumpList& otherFailureCases, const SelectorFragment&);
Split failure cases to 1. tagNameMatchFailureCases and 2. otherFailureCases.
> Source/WebCore/cssjit/SelectorCompiler.cpp:603
> + return BacktrackingAction::NoBacktracking;
For example, ".test > div div", ".test" has no tag name. So its tagNameMatchedBacktrackingStartHeightFromDescendant is InvalidHeight.
> Source/WebCore/cssjit/SelectorCompiler.cpp:607
> + return BacktrackingAction::JumpToDescendantEntryPoint;
If backtrackingStartHeightFromDescendant equals to current fragment's height, we can use current element for descendant backtracking start element since this fragment's right relation is `Child`.
> Source/WebCore/cssjit/SelectorCompiler.cpp:611
> + return BacktrackingAction::JumpToDescendantTreeWalkerEntryPoint;
If backtrackingStartHeightFromDescendant equals to current fragment's height + 1, we can use current element for child of descendant backtracking start element. So we jump to `JumpToDescendantTreeWalkerEntryPoint`.
> Source/WebCore/cssjit/SelectorCompiler.cpp:626
> + fragment.matchingOtherBacktrackingAction = solveDescendantBacktrackingActionForChild(fragment, fragment.tagNameMatchedBacktrackingStartHeightFromDescendant);
More aggressively applying `JumpToDescendantTreeWalkerEntryPoint` and `JumpToDescendantEntryPoint`.
Above old optimization is generalized by `solveDescendantBacktrackingActionForChild`.
> Source/WebCore/cssjit/SelectorCompiler.cpp:664
> + }
Now we don't apply this optimization to adjacent combinators since we need to start with simple optimization.
> Source/WebCore/cssjit/SelectorCompiler.cpp:703
> + return StrictlyEqual;
I've changed this from a proposal implementaion.
> Source/WebCore/cssjit/SelectorCompiler.cpp:713
> + return StrictlyEqual;
Same as above.
> Source/WebCore/cssjit/SelectorCompiler.cpp:-688
> - needsDescendantTail = false;
I changed these logic. Set `SaveDescendantBacktrackingStart` to flags only when needsDescendantTail becomes true.
> Source/WebCore/cssjit/SelectorCompiler.cpp:855
> + m_selectorFragments[j].backtrackingFlags |= BacktrackingFlag::InChainWithDescendantTail;
And mark between saveDescendantBacktrackingStartFragment and current fragment as InChainWithDescendantTail.
> Source/WebCore/cssjit/SelectorCompiler.cpp:857
> + saveDescendantBacktrackingStartFragmentIndex = 0;
Maybe initialized with std::numeric_limits<unsigned>::max() and inserging ASSERT(saveDescendantBacktrackingStartFragmentIndex != std::numeric_limits<unsigned>::max()); check is better?
> Source/WebCore/cssjit/SelectorCompiler.cpp:960
> +void SelectorCodeGenerator::generateWalkToParentElementWithoutElementCheck(Assembler::RegisterID targetRegister)
Extracted it.
> Source/WebCore/cssjit/SelectorCompiler.cpp:985
> + linkFailures(failureCases, fragment.matchingOtherBacktrackingAction, matchingOtherFailureCases);
This optimization works here.
> Source/WebCore/cssjit/SelectorCompiler.cpp:1067
> + linkFailures(failureCases, fragment.matchingOtherBacktrackingAction, matchingOtherFailureCases);
Currently, this optimization doesn't work here. It works as the old implementation works.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list