With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall
Bug: v8:8801, v8:8394
Change-Id: I81918f174b2f97cbaa8b8ef2e459080c2581f535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588415
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61122}
This avoids the call to the StringCharCodeAt builtin from
within TurboFan optimized code and instead emits a loop
that does the character load. This (together with previously
reverted CL to the JSCallReducer) almost completely recovers
the performance regression caused when we shipped TurboFan.
Without untrusted code mitigations the benchmark goes from
580ms to roughly 490ms, and with the patch to the JSCallReducer
the time goes down to 280ms, which is very close to what we
had with Crankshaft.
This also renames the LoadFromString helper method in the
EffectControlLinearizer to LoadFromSeqString to make it
clear what it does.
Bug: v8:7326
Change-Id: I6c77209ae01a3eacbd1e8fd40e4ad842eaf1999a
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/876102
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50725}
