- 27 Apr, 2021 1 commit
-
-
Georg Neis authored
The kInt64, kUint64, and kIntPtr type definitions made no sense. This CL removes kIntPtr and fixes+renames k(I|Ui)nt64. It also adds some DCHECKs to avoid similar bugs in the future. Bug: chromium:1202609 Change-Id: Ibe2e9c7501c22959b850d2b1076e819455440450 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2851895Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74230}
-
- 23 Apr, 2021 1 commit
-
-
Nico Hartmann authored
This CL applies the following changes: - JSCallReducer no longer generates a CheckBigInt in front of the generated BigIntAsUintN. - This results in a slight change of the semantics of the latter, which now includes the necessary type check. Typer and Verifier are changed accordingly. - The BigIntAsUintN operator is now effectful, since it can now deopt. - IrOpcode::kBigIntAsUintN is now lowered in SimplifedLowering instead of EffectControlLinearizer, the necessary type check is introduced by the RepresentationChanger. - Adds a small mjsunit test to check the correct deoptimization behavior of optimized BigInt.asUintN. ==> Remove UseInfo::TruncatingWord64()! Drive-by: Fix an issue in ChangeUnaryToPureBinaryOp when the new_input is at index 1. Drive-by: Introduce an %Is64Bit() intrinsic to allow tests to distinguish 32 and 64 bit architectures. Bug: v8:11682 Change-Id: I448f892d3bd2280d731ae5b248c833de8faf1bd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843816 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74147}
-
- 08 Jul, 2020 1 commit
-
-
Georg Neis authored
Due to an optimization in how resumable functions are compiled, we can actually see another Oddball type as StrictEquality inputs. I'm giving up on getting the DCHECK right and removing it entirely. Bug: chromium:1102683 Change-Id: Ia210777c66641e898e96900713710a51ebed311d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287494 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68735}
-
- 02 Jun, 2020 1 commit
-
-
Georg Neis authored
Bug: chromium:1085804 Change-Id: I98f12da97334bd5fd32bd01b1eca56be895dc0a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218286 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68095}
-
- 07 May, 2020 1 commit
-
-
Georg Neis authored
R=nicohartmann@chromium.org Change-Id: I55ef4e0713e0aa583ea01f1a86fee9cf0ef2c17a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184296 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67646}
-
- 05 May, 2020 1 commit
-
-
Georg Neis authored
This reverts commit a596efcc. Reason for revert: Was incorrect. Holes can appear in dead code. Original change's description: > [turbofan] Refine a DCHECK > > Hole checks are done using a lower level comparison. > > Change-Id: I61c5b787f12564ad3553d395a36938a00f5dd554 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172418 > Auto-Submit: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67466} TBR=neis@chromium.org,nicohartmann@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: I47aff68cf8e224882a3eeac0d9edfe5a6228f0f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2181324 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67561}
-
- 29 Apr, 2020 1 commit
-
-
Georg Neis authored
Hole checks are done using a lower level comparison. Change-Id: I61c5b787f12564ad3553d395a36938a00f5dd554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172418 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67466}
-
- 21 Apr, 2020 1 commit
-
-
Georg Neis authored
This reverts commit f442b03f. Reason for reland: Wrongly reverted. Original change's description: > Revert "[turbofan] Fix bug in Number.Min/Max typings" > > This reverts commit 4158af83. > > Reason for revert: causing UBSAN failures: > > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729? > > > Original change's description: > > [turbofan] Fix bug in Number.Min/Max typings > > > > They try to be very precise about when the result can be -0, > > but do so incorrectly. I'm changing the code to just do the > > simple thing instead. Let's see how that affects performance. > > > > Bug: chromium:1072171 > > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#67246} > > TBR=neis@chromium.org,tebbi@chromium.org > > Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:1072171 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646 > Reviewed-by: Francis McCabe <fgm@chromium.org> > Commit-Queue: Francis McCabe <fgm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67249} TBR=neis@chromium.org,tebbi@chromium.org,fgm@chromium.org Change-Id: Ida36ca584a5af5da887189328c8da195b26285d4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1072171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157368Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67263}
-
- 20 Apr, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 4158af83. Reason for revert: causing UBSAN failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729? Original change's description: > [turbofan] Fix bug in Number.Min/Max typings > > They try to be very precise about when the result can be -0, > but do so incorrectly. I'm changing the code to just do the > simple thing instead. Let's see how that affects performance. > > Bug: chromium:1072171 > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67246} TBR=neis@chromium.org,tebbi@chromium.org Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1072171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67249}
-
Georg Neis authored
They try to be very precise about when the result can be -0, but do so incorrectly. I'm changing the code to just do the simple thing instead. Let's see how that affects performance. Bug: chromium:1072171 Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67246}
-
- 25 Mar, 2020 1 commit
-
-
Georg Neis authored
For some input types containing -0 but not +0, the result type of NumberMin and NumberMax would unnecessarily include +0. However, for some larger inputs, the result type would not include the spurious +0, thus breaking monotonicity. The CL fixes this and addresses a TODO as well. Bug: chromium:1063661 Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66854}
-
- 18 Mar, 2020 2 commits
-
-
Georg Neis authored
"t.Is(Type::Unique())" is more conservative and future-proof than "!t.Maybe(Type::NumericOrString)". Change-Id: I7d08244802feeb062fd2f8a9d8f3af85eb43bba3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106207 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66768}
-
Georg Neis authored
We don't ever want a node's type to become less precise. Also move a part of JSTypedLowering::ReduceJSStrictEqual that can be expressed solely in terms of types into the typer, where it generalizes an existing case. Change-Id: I37c58fed48f606f6fe34e98e5f066434e50cb6c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106204 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66763}
-
- 12 Mar, 2020 1 commit
-
-
Georg Neis authored
... such that we have only a single representation for special constants such as undefined, namely the corresponding bitset. With this CL the following property holds: t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2) Also clean up the Type interface and improve test coverage a little. Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66684}
-
- 11 Mar, 2020 1 commit
-
-
Georg Neis authored
Generalize the HeapConstant case to a Singleton case. Change-Id: Ief8c325a4326e02c8c361f3b41fc40ca398167ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096619 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66659}
-
- 20 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
They have to be in sync, so this patch updates both systems. Bug: v8:4153 Change-Id: I09252e41a710e79f823fe6818c1c6c0038faeb31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903434Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65078}
-
- 19 Nov, 2019 1 commit
-
-
Nico Hartmann authored
This CL implements torque builtins for BigInt subtraction and extends the compilation pipeline to lower calls to the generic subtraction to SpeculativeBigIntSubtract and later to BigIntSubtract with necessary checks in case of BigInt feedback. The CL also implements lowering of these operators to native machine word operations on 64 bit architectures if they are used in a truncating context (aka BigInt.asUintN). Bug: v8:9407 Change-Id: Idf5da14c380bc7c12375e7f084a3e1c455303f5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895566Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65037}
-
- 16 Oct, 2019 1 commit
-
-
Sathya Gunasekaran authored
Updates CSA::TryToIntptr to handle array indices that are less than INT_MAX which allows to handle string keys in the ICs. Updates ICs to go monomorphic for string keys that are array indices. Updates Turbofan to handle array indices when lowering element access. Change-Id: Ibdde20130e075d0d645ab4a8266a968335eaad84 Bug: v8:9449 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813018Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64320}
-
- 15 Jul, 2019 1 commit
-
-
Nico Hartmann authored
This CL introduces new non-speculative operators BigIntAdd and BigIntNegate. Instead of keeping speculative operators until effect-control-linearization phase, they are now lowered to non-speculative variants in the simplified lowering and surrounded by the necessary checks. This adapts BigInt operators to the common style of other operators (like Numbers). Bug: v8:9407 Change-Id: I89ea7aef0d78c67b103971f8f63525b196ad3c0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695467 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62699}
-
- 12 Jul, 2019 1 commit
-
-
Nico Hartmann authored
This CL adds a speculative operator for BigInt negation that is lowered to the respective builtin call and is optimized to native 64 bit machine operations if truncated. In particular, this change allows negative BigInt constants (e.g. -5n) to be lowered. Bug: v8:9407 Change-Id: Ia98fd6dee18a31ce56efbe537f4352b1582539e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695463 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62684}
-
- 05 Jul, 2019 1 commit
-
-
Maya Lekova authored
Got rid of the following circular header dependency chains: compilation-dependencies <-> js-heap-broker <-> access-info types <-> js-heap-broker <-> access-info Extracted former CompilationDependencies::Dependency class into its own header. Extracted *Ref classes into their own header. This should enable building on older GCC versions, e.g. 5.4.0. Bug: v8:9440 Change-Id: Ia345bc227d8f7806d0b8622b706346a7ce6d01ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687415 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62541}
-
- 02 Jul, 2019 1 commit
-
-
Nico Hartmann authored
Operations on BigInts, for which TurboFan statically knows that they are no larger than 2^64, can be lowered to efficient machine code in TurboFan. This is the first step in doing so by generating efficient code for asUintN and the required checks and conversions. Bug: v8:9407 Change-Id: I51f6505f6c4567434fa369fcf870a09871487f51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680548 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62488}
-
- 26 Jun, 2019 1 commit
-
-
Nico Hartmann authored
This is a reland of 5ff38bae Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} Bug: v8:9213 Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62381}
-
- 25 Jun, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 5ff38bae. Reason for revert: flaky test that is not normally flaky failed. See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531 Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62364}
-
Nico Hartmann authored
This CL introduces the necessary infrastructure to generate speculative BigInt operations in case of BigInt feedback. In particular, the JSAdd operator is lowered to a speculative call to the BigIntAdd builtin, with a deopt bailout in case of exceptions or violated assumptions. Bug: v8:9213 Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62362}
-
- 24 Jun, 2019 1 commit
-
-
Mathias Bynens authored
We currently use the class name “JSValue” for JSObjects that wrap primitive values. This name is a common source of confusion. This patch switches to a name that’s more clear. In addition to manual tweaks, the patch applies the following mechanical global replacements: before | after --------------------------------|-------------------------------------- if_valueisnotvalue | if_valueisnotwrapper if_valueisvalue | if_valueiswrapper js_value | js_primitive_wrapper JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE JSPrimitiveWrapperType | JSPrimitiveWrapper type jsvalue | js_primitive_wrapper JSValue | JSPrimitiveWrapper _GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62337}
-
- 28 May, 2019 1 commit
-
-
Georg Neis authored
- Fix a non-observable bug in the typer. - Add some CHECKs where we rely on not receiving None types. - Remove an explicit handling of None types where it's redundant and misleading (later ToNumeric conversions can again introduce None). Bug: chromium:965911 Change-Id: I4bb84422de3f9297131e7304216b86884f04ed49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630679 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61880}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 22 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I79e0553e8a0d6dac2aa16b94a6c0e05b6ccde4a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621934 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61725}
-
- 18 Apr, 2019 2 commits
-
-
Georg Neis authored
We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b70118. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 57582090. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0e. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
-
Jaroslav Sevcik authored
This uses the same comparison as the ICs to make sure that ICs learn after deoptimization (see https://chromium-review.googlesource.com/c/v8/v8/+/1561319 for the IC fix). Bug: v8:9139 Change-Id: I67a361d85ee0c8a4ad4a6abc2d33ac4ca5fa22bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569438 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60917}
-
- 19 Mar, 2019 1 commit
-
-
Benedikt Meurer authored
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}
-
- 02 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
Apart from being more in-line with the style guide, this allows to use DEFINE_LAZY_LEAKY_OBJECT_GETTER for defining {TypeCache::Get}. R=tebbi@chromium.org Bug: v8:8562 Change-Id: I016b28624950ce9404180fc1ca1a232551f75cd0 Reviewed-on: https://chromium-review.googlesource.com/c/1392201Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58500}
-
- 11 Dec, 2018 1 commit
-
-
Benedikt Meurer authored
The typing of SpeculativeSafeIntegerSubtract didn't include -0, and the SimplifiedLowering rules for SpeculativeSafeIntegerSubtract didn't properly handle the case of `-0 - 0`, but would always pass Word32 truncations. Bug: chromium:913296 Change-Id: I0e5a401f075db8b349a5579e1e294df97378ea49 Reviewed-on: https://chromium-review.googlesource.com/c/1370042Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#58147}
-
- 21 Nov, 2018 1 commit
-
-
Benedikt Meurer authored
This is a reland of 585b4eef without any changes. Original change's description: > [turbofan] Improve NumberMultiply typing rule. > > The NumberMultiply typing rule gave up in the presence of NaN inputs, > but we can still infer useful ranges here and just union the result > of that with the NaN propagation (similar for MinusZero propagation). > This way we can still makes sense of these ranges at the uses. > > Bug: v8:8015 > Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92 > Reviewed-on: https://chromium-review.googlesource.com/c/1261143 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56539} Tbr: bmeurer@chromium.org Bug: v8:8015 Change-Id: I32e5c2f439a1186891ca3393ee53a2a766585839 Reviewed-on: https://chromium-review.googlesource.com/c/1345993Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57664}
-
- 19 Nov, 2018 1 commit
-
-
Georg Neis authored
This reverts commit 585b4eef. Reason for revert: Speculative, crbug 906567. Original change's description: > [turbofan] Improve NumberMultiply typing rule. > > The NumberMultiply typing rule gave up in the presence of NaN inputs, > but we can still infer useful ranges here and just union the result > of that with the NaN propagation (similar for MinusZero propagation). > This way we can still makes sense of these ranges at the uses. > > Bug: v8:8015 > Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92 > Reviewed-on: https://chromium-review.googlesource.com/c/1261143 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56539} TBR=sigurds@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8015 Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330 Reviewed-on: https://chromium-review.googlesource.com/c/1340253Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57602}
-
- 29 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This introduces Word64 support for the CheckBounds operator, which now lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the representation selection. The right hand side of CheckBounds can now be any positive safe integer on 64-bit architectures, whereas it remains Unsigned31 for 32-bit architectures. We only use the extended Word64 support when the right hand side is outside the Unsigned31 range, so for everything except DataViews this means that the performance should remain the same. The typing rule for the CheckBounds operator was updated to reflect this new behavior. The CheckBounds with a right hand side outside the Unsigned31 range will pass a new Signed64 feedback kind, which is handled with newly introduced CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation selection. The JSCallReducer lowering for DataView getType()/setType() methods was updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore, but instead just use the raw uintptr_t values and operate on any value (for 64-bit architectures these fields can hold any positive safe integer, for 32-bit architectures it's limited to Unsigned31 range as before). This means that V8 can now handle huge DataViews fully, without falling off a performance cliff. This refactoring even gave us some performance improvements, on a simple micro-benchmark just exercising different DataView accesses we go from testDataViewGetUint8: 796 ms. testDataViewGetUint16: 997 ms. testDataViewGetInt32: 994 ms. testDataViewGetFloat64: 997 ms. to testDataViewGetUint8: 895 ms. testDataViewGetUint16: 889 ms. testDataViewGetInt32: 888 ms. testDataViewGetFloat64: 890 ms. meaning we lost around 10% on the single byte case, but gained 10% across the board for all the other element sizes. Design-Document: http://bit.ly/turbofan-word64 Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383 Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83 Reviewed-on: https://chromium-review.googlesource.com/c/1303732Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
-
- 15 Oct, 2018 1 commit
-
-
Georg Neis authored
There's no ambiguity and the shorter name makes things easier to read. Bug: v8:7790 Change-Id: Ibcf3fd7f38a91e26a83cd335fad0ec80a5fe9be1 Reviewed-on: https://chromium-review.googlesource.com/c/1278392 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56623}
-
- 10 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
The NumberMultiply typing rule gave up in the presence of NaN inputs, but we can still infer useful ranges here and just union the result of that with the NaN propagation (similar for MinusZero propagation). This way we can still makes sense of these ranges at the uses. Bug: v8:8015 Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92 Reviewed-on: https://chromium-review.googlesource.com/c/1261143 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56539}
-
- 25 Sep, 2018 1 commit
-
-
Georg Neis authored
This is just a cleanup. Bug: v8:7790 Change-Id: Ic0114451159b8c504f527f3cf3bdaed6a8cc8741 Reviewed-on: https://chromium-review.googlesource.com/1243103 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56206}
-