[Webkit-unassigned] [Bug 239265] New: [JSC] Optimize switch_string in the DFG/FTL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=239265

            Bug ID: 239265
           Summary: [JSC] Optimize switch_string in the DFG/FTL
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: rmorisset at apple.com

It is particularly hot in the PDFjs part of JetStream2, and the code that we generate is horrifyingly bad.

What we currently do:
- Branch on whether the length is 0 or >0
- If it is >0 then branch on the first character
- Branch on whether the length is 1 or >1
- If it is >1 then branch on the second character,
etc..
This can very easily create a huge number of branches and BBs (e.g. 300 BBs for a single tiny function in PDFjs), and makes us take 2 branches for every character.

What we should do:
- Switch on the string length
- Then switch on the first 64 bits of the string at once
- Then the next 64 bits, etc.. as long as there are >= 64 bits left
- Then the next 32 bits if there are >= 32 bits left
- Then the next 16 bits if there are >= 16 bits left
- Then finally 8 bits if there are 8 bits left

This should reduce our asymptotic number of branches executed by 16, and if the length does not match any of the strings we are trying to match against, then we would have a single branch instead of 2*n with n being the min of the length of the tested string and the length of the longest constant we are matching against.

>From profiling PDFjs I'd expect a nearly 10% speedup of it by fixing this pathology. It should also help a bit the compile times of B3 for that kind of code, by reducing the ridiculous number of BBs that we generate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220413/e043527c/attachment.htm>