- 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}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 15 Nov, 2018 1 commit
-
-
Ross McIlroy authored
With Bytecode flushing, the a SharedFunctionInfo's bytecode might be flushed while the compiler is expecting it to still exist. Rather than continually getting the bytecode from the SFI, instead bottleneck the points where we get BytecodeArray from SFIs and maintain an explicit strong reference to the BytecodeArray from that point onwards to prevent flushing. BUG=v8:8395 Change-Id: I6a18adec99402838690971eb37ee0617cdc15920 Reviewed-on: https://chromium-review.googlesource.com/c/1309763 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57536}
-
- 10 Apr, 2018 1 commit
-
-
Matheus Marchini authored
Before Turbofan/Ignition it was possible to use external profilers to sample running V8/Node.js processes and generate reports/FlameGraphs from that. It's still possible to do so, but non-optimized JavaScript functions appear in the stack as InterpreterEntryTrampoline. This commit adds a runtime flag which makes interpreted frames visible on the process' native stack as distinguishable functions, making the sampled data gathered by external profilers such as Linux perf and DTrace more useful. R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com Bug: v8:7155 Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415 Reviewed-on: https://chromium-review.googlesource.com/959081 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52533}
-
- 04 Apr, 2018 1 commit
-
-
Ross McIlroy authored
With the Ignition + Turbofan pipeline there is very little overlap between the data needed for unoptimized compilation and optimized compilation. As a result, it is cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and OptimizedCompilationInfo. Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob and OptimizedCompilationJob - again there is not much overlap so this seems cleaner. Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a Reviewed-on: https://chromium-review.googlesource.com/995895 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52369}
-
- 22 Sep, 2017 1 commit
-
-
Georgia Kouveli authored
Add padding for the interpreter registers when needed, to make the interpreter frame a multiple of 16 bytes. The padding needs to be added in the InterpreterEntryTrampoline and when generating an interpreter frame in the deoptimizer. It also needs to be considered when calculating the size of the interpreter frame during OSR and stack unwinding. Bug: v8:6644 Change-Id: Icfec94079cf0785fc8a2506ff555b5f9e89e3d13 Reviewed-on: https://chromium-review.googlesource.com/664563 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48121}
-
- 10 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Deletes AstGraphBuilder and associated classes now that it is unreachable. The following classes are also removed: - ControlBuilders - JSFrameSpecialization - AstLoopAssignmentAnalysis Also removes flags from compilation-info which are no longer used, and removes the no-deoptimization paths from TypedOptimization, JsTypedLowering, JSIntrinsicLowering and JSBuiltinLowering. BUG=v8:6409 Change-Id: I63986e8e3497bf63c4a27ea8ae827b8a633d4a26 Reviewed-on: https://chromium-review.googlesource.com/583652 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47284}
-
- 09 Aug, 2017 1 commit
-
-
Mostyn Bramley-Moore authored
To speed up compilation times, jumbo allows files to be compiled together. This is a well known method ("unity builds") to both compile faster and create a poor man's "full program optimization". We are only interested in compile times. Background: https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md Note that jumbo builds are not enabled by default. To try this out, add use_jumbo_build=true to your GN args. BUG=chromium:746958 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ieb9fdccb6c135e9806dbed91c09a29aa8b8bee11 Reviewed-on: https://chromium-review.googlesource.com/579090 Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47239}
-
- 26 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Reland of https://chromium-review.googlesource.com/c/543042/. Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14 Reviewed-on: https://chromium-review.googlesource.com/584756 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46899}
-
- 21 Jul, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 69c8f16d. Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154 BUG=chromium:747154 Original change's description: > [Turbofan] Merged the OSR phase into the graph building phase. > > Now the OSR phase is only used when OSRing from the ast graph builder. > When OSRing from Turbofan, the implementation is now in the graph > building phase, at the beginning of the VisitBytecode function. > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, > nor nodes for the possible code of the OSRed function which is before > the OSRed loops. > > The trimming and reducing of the OSR phase is not done either. This > change in the way the way the OSR is done enabled to remove the > workaround to the bug mentioned below. > > Bug: v8:6112 > Bug: v8:6518 > Change-Id: I1c9231810b923486d55ea618d550d981d695d797 > Reviewed-on: https://chromium-review.googlesource.com/543042 > Commit-Queue: Alexandre Talon <alexandret@google.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46801} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6112, v8:6518 Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46817}
-
- 20 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: I1c9231810b923486d55ea618d550d981d695d797 Reviewed-on: https://chromium-review.googlesource.com/543042 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46801}
-
- 28 Apr, 2017 1 commit
-
-
jarin authored
BUG=v8:6325 Review-Url: https://codereview.chromium.org/2851723002 Cr-Commit-Position: refs/heads/master@{#44974}
-
- 21 Mar, 2017 1 commit
-
-
bmeurer authored
BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2762143002 Cr-Commit-Position: refs/heads/master@{#43986}
-
- 05 Dec, 2016 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org BUG= Review-Url: https://codereview.chromium.org/2549093002 Cr-Commit-Position: refs/heads/master@{#41486}
-
- 06 Oct, 2016 1 commit
-
-
jarin authored
Reland of "[turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )" Fixes: - Remove OsrGuards on frame specialization (for asm.js). - Handle the rename in the walk for native context. - Fix LoadContext effect wiring for Osr context chains. Review-Url: https://codereview.chromium.org/2388303006 Cr-Commit-Position: refs/heads/master@{#40021}
-
- 05 Oct, 2016 2 commits
-
-
jarin authored
Revert of [turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ ) Reason for revert: Tanks the world. Original issue's description: > [turbofan] Osr value typing + dynamic type checks on entry. > > This introduces a new OsrGuard node that is inserted during graph building > to guard the inferred type of the OSR value. > > The type of the OSR value is inferred by running the typer before OSR > deconstruction, and then taking the type from the phi that takes the > OSR value. After the deconstruction, we throw the types away. > > At the moment we only support the SignedSmall OSR type and we always > pick the tagged representation. Later, we might want to support more > types (such as Number) and pick better representations (int32/float64). > > This CL also removes the OSR deconstruction tests because they build > unrealistic graph (no effect chain, no loop termination). I considered > adding the effect chains to the tests, but this would make the tests > even more brittle. > > Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076 > Cr-Commit-Position: refs/heads/master@{#39971} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2395783002 Cr-Commit-Position: refs/heads/master@{#39985}
-
jarin authored
This introduces a new OsrGuard node that is inserted during graph building to guard the inferred type of the OSR value. The type of the OSR value is inferred by running the typer before OSR deconstruction, and then taking the type from the phi that takes the OSR value. After the deconstruction, we throw the types away. At the moment we only support the SignedSmall OSR type and we always pick the tagged representation. Later, we might want to support more types (such as Number) and pick better representations (int32/float64). This CL also removes the OSR deconstruction tests because they build unrealistic graph (no effect chain, no loop termination). I considered adding the effect chains to the tests, but this would make the tests even more brittle. Review-Url: https://codereview.chromium.org/2384113002 Cr-Commit-Position: refs/heads/master@{#39971}
-
- 12 Sep, 2016 1 commit
-
-
mstarzinger authored
It is invalid for OSR deconstruction to leave a graph with a node representing the OSR normal entry (and no OSR loop entry). Subsequent lowering phases will not handle {OsrNormalEntry} operators and hence will lead to serious clogging further down the pipeline. R=bmeurer@chromium.org BUG=chromium:641893 Review-Url: https://codereview.chromium.org/2336543002 Cr-Commit-Position: refs/heads/master@{#39340}
-
- 09 Sep, 2016 1 commit
-
-
marja authored
TBR=bmeurer@chromium.org BUG=v8:5294 Review-Url: https://codereview.chromium.org/2324783002 Cr-Commit-Position: refs/heads/master@{#39304}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
This way, many files which only need CompilationInfo but not compiler.h and its dependencies can include just compilation-info.h. BUG= Review-Url: https://codereview.chromium.org/2284313003 Cr-Commit-Position: refs/heads/master@{#39038}
-
- 09 Aug, 2016 1 commit
-
-
bgeron authored
R=danno,jarin BUG= Review-Url: https://codereview.chromium.org/2226293002 Cr-Commit-Position: refs/heads/master@{#38502}
-
- 27 Jul, 2016 1 commit
-
-
mstarzinger authored
This implements graph construction for entry via on-stack replacement within the {BytecodeGraphBuilder}. Entry points are at loop headers similar to previous OSR implementations. All interpreter registers are addressable via {OsrValue} nodes in the graph. Currently we rely on {OsrPoll} bytecodes to be placed right after loop headers (i.e. at the targets of back edges). R=jarin@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2171083004 Cr-Commit-Position: refs/heads/master@{#38083}
-
- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 24 Sep, 2015 1 commit
-
-
mstarzinger authored
This introduces the NodeProperties::ChangeOp helper which guards node operator changes so that additional checking can be done without any additional dependencies being pulled into the Node class. For now only the input count is checked, but additional checking might follow. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1366753003 Cr-Commit-Position: refs/heads/master@{#30916}
-
- 16 Sep, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1348073002 Cr-Commit-Position: refs/heads/master@{#30764}
-
- 18 Aug, 2015 1 commit
-
-
danno authored
Previously, it was not possible to specify StackSlotOperands for all slots in both the caller and callee stacks. Specifically, the region of the callee's stack including the saved return address, frame pointer, function pointer and context pointer could not be addressed by the register allocator/gap resolver. In preparation for better tail call support, which will use the gap resolver to reconcile outgoing parameters, this change makes it possible to address all slots on the stack, because slots in the previously inaccessible dead zone may become parameter slots for outgoing tail calls. All caller stack slots are accessible as they were before, with slot -1 corresponding to the last stack parameter. Stack slot indices >= 0 access the callee stack, with slot 0 corresponding to the callee's saved return address, 1 corresponding to the saved frame pointer, 2 corresponding to the current function context, 3 corresponding to the frame marker/JSFunction, and slots 4 and above corresponding to spill slots. The following changes were specifically needed: * Frame has been changed to explicitly manage three areas of the callee frame, the fixed header, the spill slot area, and the callee-saved register area. * Conversions from stack slot indices to fp offsets all now go through a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp * The generation of deoptimization translation tables has been changed to support the new stack slot indexing scheme. Crankshaft, which doesn't support the new slot numbering in its register allocator, must adapt the indexes when creating translation tables. * Callee-saved parameters are now kept below spill slots, not above, to support saving only the optimal set of used registers, which is only known after register allocation is finished and spill slots have been allocated. Review URL: https://codereview.chromium.org/1261923007 Cr-Commit-Position: refs/heads/master@{#30224}
-
- 06 Jul, 2015 3 commits
-
-
bmeurer authored
[turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.". We have to reland these two commits at once, because the first breaks some asm.js benchmarks without the second. The change was reverted because of bogus checks in the verifier, which will not work in the presence of OSR (and where hidden because of the type back propagation hack in OSR so far). Original messages are below: [turbofan] Add new JSFrameSpecialization reducer. The JSFrameSpecialization specializes an OSR graph to the current unoptimized frame on which we will perform the on-stack replacement. This is used for asm.js functions, where we cannot reuse the OSR code object anyway because of context specialization, and so we could as well specialize to the max instead. It works by replacing all OsrValues in the graph with their values in the JavaScriptFrame. The idea is that using this trick we get better performance without doing the unsound backpropagation of types to OsrValues later. This is the first step towards fixing OSR for TurboFan. [turbofan] Perform OSR deconstruction early and remove type propagation. This way we don't have to deal with dead pre-OSR code in the graph and risk optimizing the wrong code, especially we don't make optimistic assumptions in the dead code that leaks into the OSR code (i.e. deopt guards are in dead code, but the types propagate to OSR code via the OsrValue type back propagation). BUG=v8:4273 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/1226673005 Cr-Commit-Position: refs/heads/master@{#29486}
-
machenbach authored
Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation." This reverts commit b0a852e8. This reverts commit cdbb6c48. NOTRY=true NOTREECHECKS=true BUG=v8:4273 LOG=n TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1225743002 Cr-Commit-Position: refs/heads/master@{#29480}
-
bmeurer authored
This way we don't have to deal with dead pre-OSR code in the graph and risk optimizing the wrong code, especially we don't make optimistic assumptions in the dead code that leaks into the OSR code (i.e. deopt guards are in dead code, but the types propagate to OSR code via the OsrValue type back propagation). BUG=v8:4273 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/1215333005 Cr-Commit-Position: refs/heads/master@{#29478}
-
- 19 Jun, 2015 1 commit
-
-
bmeurer authored
The three different concerns that the ControlReducer used to deal with are now properly separated into a.) DeadCodeElimination, which is a regular AdvancedReducer, that propagates Dead via control edges, b.) CommonOperatorReducer, which does strength reduction on common operators (i.e. Branch, Phi, and friends), and c.) GraphTrimming, which removes dead->live edges from the graph. This will make it possible to run the DeadCodeElimination together with other passes that actually introduce Dead nodes, i.e. typed lowering; and it opens the door for general inlining without two stage fix point iteration. To make the DeadCodeElimination easier and more uniform, we basically reverted the introduction of DeadValue and DeadEffect, and changed the Dead operator to produce control, value and effect. Note however that this is not a requirement, but merely a way to make dead propagation easier and more uniform. We could always go back and decide to have different Dead operators if some other change requires that. Note that there are several additional opportunities for cleanup now, i.e. OSR deconstruction could be a regular reducer now, and we don't need to use TheHole as dead value marker in the GraphReducer. And we can actually run the dead code elimination together with the other passes instead of using separate passes over the graph. We will do this in follow up CLs. R=jarin@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1193833002 Cr-Commit-Position: refs/heads/master@{#29146}
-
- 17 Jun, 2015 1 commit
-
-
bmeurer authored
Up until now that was still mixed with control reduction in the ControlReducer. This separation allows us to remove the horrible Reducer::Finish hack and also do graph trimming at more appropriate places in the pipeline (i.e. trim dead nodes after generic lowering, which can also make nodes dead). R=jarin@chromium.org,mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1188433010 Cr-Commit-Position: refs/heads/master@{#29077}
-
- 12 Jun, 2015 1 commit
-
-
bmeurer authored
Up until now we used int32_t for NodeId, but that was not ideal because negative values are invalid for NodeId and we use it as an array index for example in the NodeMarker class, where C++ compilers on x64 have to generate code that does proper sign extension for the indices, which is completely unnecessary. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1178403004 Cr-Commit-Position: refs/heads/master@{#28997}
-
- 26 May, 2015 1 commit
-
-
bmeurer authored
This simplifies the handling of the End node. Based on this CL we will finally fix terminating every loop from the beginning (via Terminate nodes) and fix inlining of Throw, Deoptimize and Terminate. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1157023002 Cr-Commit-Position: refs/heads/master@{#28620}
-
- 06 May, 2015 1 commit
-
-
bmeurer authored
An AdvancedReducer is basically a regular Reducer with an editor that can perform graph editing operations beyond changing or replacing the node that is currently being reduced. The GraphReducer is the default implementation of the AdvancedReducer::Editor interface. The ControlReducerImpl is now just an AdvancedReducer, which temporarily requires a Finish method in the reducer to implement the dead node trimming until we move that to the GraphReducer (which in turn requires that all loops are connected to End). Review URL: https://codereview.chromium.org/1122423003 Cr-Commit-Position: refs/heads/master@{#28251}
-
- 27 Apr, 2015 1 commit
-
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1105133002 Cr-Commit-Position: refs/heads/master@{#28083}
-
- 17 Mar, 2015 1 commit
-
-
titzer authored
In constructing the transfer between loop copies, we need to merge the backedges from all the previous copies of the given loop. The control reduction will work out which ones are really reachable. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1004993004 Cr-Commit-Position: refs/heads/master@{#27246}
-
- 19 Feb, 2015 2 commits
-
-
titzer authored
R=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/930003003 Cr-Commit-Position: refs/heads/master@{#26746}
-
titzer authored
AstGraphBuilder puts a constant context in from the beginning. Also fix bug in merging contexts in environment. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/934293002 Cr-Commit-Position: refs/heads/master@{#26745}
-
- 17 Feb, 2015 2 commits
-
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/921083004 Cr-Commit-Position: refs/heads/master@{#26705}
-
titzer authored
Note OSR special case. Also improved robustness of OSR tests. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/920573004 Cr-Commit-Position: refs/heads/master@{#26686}
-