| Summary: | JIT support for SSE4a | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | yhardy.public | ||||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Enhancement | CC: | berto, calvin.walton, fpizlo, keith_miller, mark.lam, mcatanzaro, msaboff, nekohayo, saam, smoley, tzagallo, webkit-bug-importer, ysuzuki | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Local Build | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
yhardy.public
2021-01-22 23:28:25 PST
Created attachment 418217 [details]
A patch for the offlineasm part (incomplete, needs feature test)
This patch is similar to the JIT patch, but I could not find the feature test for rounding. So the patch is incomplete until the feature test is added.
Since precision of x87 and SSE are different, we should not mix both. So, 1. In LLInt, let's just use slow path function calls instead in x64. 2. In Wasm Air tier, we should emit function call nodes instead of using CeilDouble etc. if supportsFloatingPointRounding() returns false. 3. In Wasm OMG tier, we do not need to do anything since B3::Ceil etc. is automatically converted into function calls if supportsFloatingPointRounding is false. Could you upload a patch with webkit-patch? We need ChangeLog update where we need very descriptive explanation about the change. Apologies for taking so very long to reply. Would you like me to upload the (incorrect) patch? Unfortunately my hardware stopped working, so I cannot test the patch on real hardware anymore and I am not sure what the best way is to proceed (I guess very few people still have these CPUs). *** Bug 222805 has been marked as a duplicate of this bug. *** We have an affected user in #epiphany:gnome.org who would no doubt be happy to test an updated patch (or -- better -- a pull request) for this issue, should somebody decide to provide one. Indeed I do have access to such hardware for testing* because my parents have a desktop computer running Fedora 38 with an AMD Phenom™ 9600B quad-core processor that otherwise runs pretty well. Wikipedia tells me the AMD Phenom II series also have this same sort of limitation. While testing, I was able to confirm that running with "JavaScriptCoreUseJIT=0" avoided the crash. To reproduce on my end (with those CPUs), with WebKitGtk's "MiniBrowser" or with Epiphany, it's as simple as clicking on any link to a PDF file on the web; as the browsers will try to open it with the built-in pdf.js viewer by default, it will trigger a crash 100% of the time because it tries to use "roundsd". A side-effect of such crashes is that the system can then become unresponsive because preinstalled tools like systemd-coredump automatically try to catch, compress and store (and possibly further process) the crashes every time, which can lead to a lot of I/O, CPU and disk usage, and overall lack of responsiveness of the system while the user is trying to use it, and it's not immediately obvious that it crashed behind the scenes. *: presuming I can use some sort of prebuilt package to test ideally, because I don't think I would be able to compile WebKit by myself on that machine with 4 GB of RAM ;) |