This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from

  serializeNaive: 10762 ms.
  serializeClever: 7813 ms.
  serializeConcat: 10271 ms.

to

  serializeNaive: 10278 ms.
  serializeClever: 5533 ms.
  serializeConcat: 10310 ms.

which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.

This was accomplished via a couple of different steps, which are briefly
outlined here:

  1. The empty_string gets its own map, so that we can easily recognize
     and handle it appropriately in the TurboFan type system. This
     allows us to express (and assert) that the inputs to NewConsString
     are non-empty strings, making sure that TurboFan no longer creates
     "crippled ConsStrings" with empty left or right hand sides.
  2. Further split the existing String types in TurboFan to be able to
     distinguish between OneByte and TwoByte strings on the type system
     level. This allows us to avoid having to dynamically lookup the
     resulting ConsString map in case of ConsString creation (i.e. when
     we know that both input strings are OneByte strings or at least
     one of the input strings is TwoByte).
  3. We also introduced more finegrained feedback for the Add bytecode
     in the interpreter, having it collect feedback about ConsStrings,
     specifically ConsOneByteString and ConsTwoByteString. This feedback
     can be used by TurboFan to only inline the relevant code for what
     was seen so far. This allows us to remove the Octane/Splay specific
     magic in JSTypedLowering to detect ConsString creation, and instead
     purely rely on the feedback of what was seen so far (also making it
     possible to change the semantics of NewConsString to be a low-level
     operator, which is only introduced in SimplifiedLowering by looking
     at the input types of StringConcat).
  4. On top of the before mentioned type and interpreter changes we added
     new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
     CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
     checks.

There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.

Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}