[Webkit-unassigned] [Bug 210685] REGRESSION(r251875): Crash in JSC::StructureIDTable::get on ppc64le: gcSafeMemcpy broken on JSVALUE64 platforms other than x86_64 and aarch64

[bugzilla-daemon at webkit.org]

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

--- Comment #34 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Daniel Kolesa from comment #30)
> Doing that results in needless branches being taken based on
> smallCutoff/mediumCutoff, which just falling back to slow path early
> prevents...

OK, you're right. That would be avoided by my proposed follow-up patch, though. If you prefer, we can do it all in one patch. In WebKit we have an annoying rule that you only attach one patch per bug report, so we have a tendency to solve multiple slightly-related things in the same patch that might be expected to be two separate patches in other projects. We can fix it with build guards and also clean up the guards all in one. Here's what I was thinking:

```
#if USE(JSVALUE64)
#if COMPILER(GCC_COMPATIBLE) && (CPU(X86_64) || CPU(ARM64))
if (bytes <= smallCutoff) {
    slow path
} else if (aarch64 || bytes <= mediumCutoff) {
#if CPU(X86_64)
    x86_64 fast path
#elif CPU(ARM64)
    aarch64 fast path
#endif
} else {
    assert(x86_64)
#if (X86_64)
    x86_64 fast path
#endif
}
#else // non-x86_64/aarch64 or non-GCC-compatible JSVALUE64 path
    slow path
#else // JSVALUE32 path
    vanilla memcpy
#endif
```

I think that's the simplest we can get it down to (for some value of "simple"). Then we'd make the same change in the other two functions as well, adding && (CPU(X86_64) || CPU(ARM64)) guards at the top of the chain so that we can compress the non-GCC compat and non-x86_64/aarch64 fallbacks together. Do you agree that makes sense?

I can upload a patch if you want, but you get your name in the commit message if you try. ;) We can also go with your simple patch here, but I would wind up basically undoing the change in that follow-up.

-- 
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/20200507/40df42fa/attachment-0001.htm>