[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