Commit Graph

13 Commits

Author SHA1 Message Date
Georg Neis
aff70262f1 [test] Crash on invalid intrinsic use unless --fuzzing is on
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.

The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
  optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
  is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
  optimized code.

Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
2020-04-14 15:01:49 +00:00
Ross McIlroy
69a71cba40 [Test] Add PrepareForOptimization to inspector tests
Bug: v8:8801, v8:8394
Change-Id: I7f27cb0a9dcbdd1ba0e3f90735472408c22185e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593304
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61182}
2019-05-02 16:01:41 +00:00
Ross McIlroy
73ec55982c Reland "[Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile"
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
> 
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
> 
> Also does some other cleanup:
>  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
>  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
>    out of FinalizeUnoptimizedCompile.
> 
> BUG=v8:6409
> 
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}

TBR=yangguo@chromium.org
TBR=jarin@chromium.org

Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
2017-08-17 13:21:44 +00:00
Ross McIlroy
0f40415b6b Revert "[Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile"
This reverts commit 21da12a983.

Reason for revert: Failing on arm64 simulator

Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
> 
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
> 
> Also does some other cleanup:
>  - Removes CompileUnoptimizedFunction and inlines into new Compiler function
>  - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
>    out of FinalizeUnoptimizedCompile.
> 
> BUG=v8:6409
> 
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org

Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
2017-08-17 11:00:15 +00:00
Ross McIlroy
21da12a983 [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.

Also does some other cleanup:
 - Removes CompileUnoptimizedFunction and inlines into new Compiler function
 - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
   out of FinalizeUnoptimizedCompile.

BUG=v8:6409

Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
2017-08-17 09:47:57 +00:00
Alexey Kozyatinskiy
a8176a530c [ignition] removed nop bytecode
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them.

There are at least two changes which this CL produce:
- we don't provide break position when we load local variable (still provide when load variable from global),
- we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement.

More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing

Bug: v8:6425
Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda
Reviewed-on: https://chromium-review.googlesource.com/543161
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-18 16:14:29 +00:00
Alexey Kozyatinskiy
0896586083 [inspector] improve return position of explicit return in non-async function
Goal of this CL: explicit return from non-async function has position after
return expression as return position (will unblock [1]).

BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
If one of these methods is called then next generated bytecode will get passed
position. It's general treatment for most cases.
Unfortunately it doesn't work for Returns:
- debugger requires source positions exactly on kReturn bytecode in stepping
  implementation,
- BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
  generates more then one bytecode and general solution will put return position
  on first generated bytecode,
- it's not easy to split BuildReturn function into two parts to allow something
  like following in BytecodeGenerator::VisitReturnStatement since generated
  bytecodes are actually controlled by execution_control().
..->BuildReturnPrologue();
..->SetReturnPosition(stmt);
..->Return();

In this CL we pass ReturnStatement through ExecutionControl and use it for
position when we emit return bytecode right here.

So this CL only will improve return position for returns inside of non-async
functions, I'll address async functions later.

[1] https://chromium-review.googlesource.com/c/543161/

Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
Reviewed-on: https://chromium-review.googlesource.com/560738
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 19:10:13 +00:00
Aleksey Kozyatinskiy
fb6a094db5 [inspector] moved var initialization break location before init expression (reland)
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
Benefits (see test for details):
 - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
 - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
 
TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:5909

Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294
Reviewed-on: https://chromium-review.googlesource.com/518116
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45598}
2017-05-30 12:54:49 +00:00
Michael Achenbach
ee1db48cc3 Revert "[inspector] moved var initialization break location before init expression"
This reverts commit 7a9cc70492.

Reason for revert: Changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882

This is about:
inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html

Original change's description:
> [inspector] moved var initialization break location before init expression
> 
> This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
> Benefits (see test for details):
> - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
> - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.
> 
> Bug: v8:5909
> Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
> Reviewed-on: https://chromium-review.googlesource.com/513926
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45530}

TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:5909

Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f
Reviewed-on: https://chromium-review.googlesource.com/518102
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45547}
2017-05-29 07:03:23 +00:00
Alexey Kozyatinskiy
7a9cc70492 [inspector] moved var initialization break location before init expression
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position.
Benefits (see test for details):
- only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2),
- removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}.

Bug: v8:5909
Change-Id: I039d911903a2826c9859710a63ab0462c992e11b
Reviewed-on: https://chromium-review.googlesource.com/513926
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45530}
2017-05-25 14:51:17 +00:00
clemensh
20defd29e0 [asm.js] [inspector-test] Avoid breakpoint on "use asm" statement
Ignition does not emit any byte code for some literal expression
statements, so avoid testing for it.

R=rmcilroy@chromium.org
BUG=v8:5757

Review-Url: https://codereview.chromium.org/2612013002
Cr-Commit-Position: refs/heads/master@{#42067}
2017-01-04 13:29:35 +00:00
yangguo
70bedcb1ef [debugger] do not use asm validator for debug code.
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2492713005
Cr-Commit-Position: refs/heads/master@{#40934}
2016-11-11 15:13:31 +00:00
clemensh
1cac34ed6b Fix detection of BUILTIN functions
In the asm.js to wasm pipeline, we generate an entry function with
BUILTIN code, but still attached to a TYPE_NORMAL script.
This fix avoids trying to set a breakpoint there, resulting in a crash
on DCHECK(shared->HasDebugInfo()).

Also add two inspector tests to track regressions.

BUG=v8:5568
R=titzer@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2457433002
Cr-Commit-Position: refs/heads/master@{#40633}
2016-10-28 06:48:44 +00:00