- 22 Aug, 2016 1 commit
-
-
bmeurer authored
This adds cached versions of the DeoptimizeIf, DeoptimizeUnless and Deoptimize operators that occur most often in various benchmarks. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2266743002 Cr-Commit-Position: refs/heads/master@{#38769}
-
- 11 Aug, 2016 1 commit
-
-
bgeron authored
BUG= Review-Url: https://codereview.chromium.org/2227763004 Cr-Commit-Position: refs/heads/master@{#38586}
-
- 05 Aug, 2016 1 commit
-
-
jarin authored
If we infer loop variable bounds, we need to insert a type rename node (sigma) to make sure that simplified lowering can choose representations consistently. Review-Url: https://codereview.chromium.org/2222513002 Cr-Commit-Position: refs/heads/master@{#38391}
-
- 02 Aug, 2016 2 commits
-
-
mstarzinger authored
This completely removes translation of exception handler predictions from the graph IR. We now rely on the runtime using deoptimization infomation via {FrameSummary} for predictions in optimized code. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2207533002 Cr-Commit-Position: refs/heads/master@{#38250}
-
bmeurer authored
This adds support for lowering keyed access to JSTypedArray objects to element loads and stores instead of IC calls. There's still a lot of room for improvement, but the improvements can be done incrementally later. We add a dedicated UnsafePointerAdd operator, which sits in the effect chain, and does the (GC invisible) computation of addresses that are potentially inside HeapObjects. Also there's now a dedicated Retain operator, which ensures that we retain a certain tagged value, which is necessary to ensure that we keep a JSArrayBuffer alive as long as we might still potentially access elements in its backing store. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2203693002 Cr-Commit-Position: refs/heads/master@{#38235}
-
- 27 Jul, 2016 1 commit
-
-
jarin authored
The new phase will detect loop variable, infer bounds and bake them into the type. Review-Url: https://codereview.chromium.org/2164263003 Cr-Commit-Position: refs/heads/master@{#38077}
-
- 22 Jul, 2016 1 commit
-
-
yangguo authored
This is in preparation to implementing exception prediction for async functions. Each handler table entry can now predict "caught", "uncaught", or "promise". The latter indicates that the exception will lead to a promise rejection. To mark the relevant try-catch blocks, we add a new native syntax. try { } %catch (e) { } indicates a TryCatchStatement with the "promise" prediction. The previous implementation of using the function to tell the relevant try-catch apart from inner try-catch blocks will not work for async functions since these can have inner try-catch blocks inside the same function. BUG=v8:5167 Review-Url: https://codereview.chromium.org/2161263003 Cr-Commit-Position: refs/heads/master@{#37966}
-
- 21 Jul, 2016 1 commit
-
-
bmeurer authored
We can actually eliminate certain effectful operations like loads and speculative number operations during representation selection if we discover that their value outputs are unused (we also propagate this information through pure operations as well, so that we remove the maximum number of effectful nodes possible). R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2168023002 Cr-Commit-Position: refs/heads/master@{#37928}
-
- 18 Jul, 2016 1 commit
-
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-
- 15 Jul, 2016 1 commit
-
-
bgeron authored
With this patch, every node in turbo-*.json has an opcode, a title, and a label. The label field is new; the opcode and title were already there. The title is for the mouseover text. The label is what will be displayed in the graph view, unless it's too long, in which case only the opcode will be displayed. (This is similar to the preexisting behaviour of putting titles in labels, except that the titles were rarely short enough to fit in a label.) With this patch, the labels generated are in practice the same as the titles we had before, except for LoadField and StoreField, which will be rendered as LoadField[[+432]] and StoreField[[+432]] (if 432 was the offset). This diff adds an overloadable method virtual void Operator1<T>::PrintParameter(ostream&, PrintVerbosity) for each type T to Operator1. Its default implementation just uses operator<<(ostream&, T const&) and adds square brackets around it, but it is overridden for FieldAccess to print "[+432]" in the example case. BUG= R=jarin,danno Review-Url: https://codereview.chromium.org/2093013002 Cr-Commit-Position: refs/heads/master@{#37795}
-
- 14 Jul, 2016 1 commit
-
-
jarin authored
This CL introduces explicit LoopExit control nodes at loop exits. We also attach explicit value renames (LoopExitMarker) and effect rename (LoopExitEffect) to each loop exit. This is in preparation to loop peeling, which will replace LoopExit, LoopExitMarker and LoopExitEffect with Merge, Phi and EffectPhi respectively. At the moment, we insert loop exit at every return, break, continue and locally caught throw. We do not yet handle uncaught throws (including error throws, such as ReferenceError). Review-Url: https://codereview.chromium.org/2140673007 Cr-Commit-Position: refs/heads/master@{#37769}
-
- 21 Jun, 2016 1 commit
-
-
bmeurer authored
Add control dependencies to Projection and Int32Add/SubWithOverflow operators, to prevent the scheduler from moving the Projection nodes into the wrong place. This way the instruction selection can combine the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and CheckedInt32Sub so that we can delay the actual lowering until the effect/control linearizer. This also makes CheckIf operator obsolete, so we can drop it. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2082993002 Cr-Commit-Position: refs/heads/master@{#37148}
-
- 20 Jun, 2016 1 commit
-
-
bmeurer authored
These are used to check for Smi or HeapObject, and we use them appropriately in JSNativeContextSpecialization, so we don't need to introduce dependencies on concrete control flow and/or concrete frame states. They will be optimized by a proper check elimination reducer, which will be added in a separate CL. R=jarin@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2082523002 Cr-Commit-Position: refs/heads/master@{#37096}
-
- 06 Jun, 2016 1 commit
-
-
bgeron authored
Previously, ZoneVector<MachineType>* printed just as a pointer; now we print each MachineType in it, separated by commas. BUG= Review-Url: https://codereview.chromium.org/2030323002 Cr-Commit-Position: refs/heads/master@{#36736}
-
- 01 Jun, 2016 2 commits
-
-
mstarzinger authored
This is a first step towards explicit checkpoints in the graph. For now we still use the explicit eager bailout points in the AstGraphBuilder that are marked by the FrameStateBeforeAndAfter helper. Eventually these will be implicitly emitted by expression visits having a side-effect. R=bmeurer@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2018403002 Cr-Commit-Position: refs/heads/master@{#36638}
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2022033004 Cr-Commit-Position: refs/heads/master@{#36637}
-
- 24 May, 2016 1 commit
-
-
bmeurer authored
The DeoptimizeIf and DeoptimizeUnless operators should actually produce an effect in addition to the control output. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2002253003 Cr-Commit-Position: refs/heads/master@{#36477}
-
- 18 May, 2016 2 commits
-
-
bmeurer authored
The type guard should never be used after the effect/control linearization pass, so making it a simplified operator better expresses the intended use. Also this way none of the common operators actually has any dependency on the type system. Drive-by-fix: Properly print the type parameter to a TypeGuard operator. BUG=chromium:612142 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/1994503002 Cr-Commit-Position: refs/heads/master@{#36304}
-
bmeurer authored
This operator will be used to carry eager frame states, and is hooked up to the effect chain with a control dependency to avoid hosting out of control structures. R=jarin@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/1993593002 Cr-Commit-Position: refs/heads/master@{#36301}
-
- 06 May, 2016 1 commit
-
-
bmeurer authored
This operator was initially designed to handle arbitrary effect merging for effect relaxation, but we don't do that (at least currently). So no need to keep the dead operator around. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/1954983002 Cr-Commit-Position: refs/heads/master@{#36063}
-
- 04 May, 2016 1 commit
-
-
gdeepti authored
Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers to update wasm memory size references in generated code. - Add new RelocInfo mode WASM_MEMORY_SIZE_REFERENCE in the assembler and add relocation information to immediates in compare instructions. - Use relocatable constants for MemSize/BoundsCheck in the wasm compiler R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Review-Url: https://codereview.chromium.org/1921203002 Cr-Commit-Position: refs/heads/master@{#36044}
-
- 18 Apr, 2016 1 commit
-
-
mstarzinger authored
This introduces a dedicated getter to extract call descriptors from operators of call nodes (i.e. call and tail-call) to ensure that all accesses are const-correct. An implicit cast of constness is undefined behavior and hard to spot without sanitization. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1894983002 Cr-Commit-Position: refs/heads/master@{#35570}
-
- 15 Apr, 2016 1 commit
-
-
ahaas authored
The default NaN mode was originally used to identify holes in double arrays. With (https://codereview.chromium.org/863633002/) signalling NaNs are used for that, and the default NaN mode is not needed anymore. Without the default NaN mode it is easier to satisfy the WebAssembly spec which requires that quiet NaNs are preserved. R=titzer@chromium.org, rodolph.perfetta@arm.com, bmeurer@chromium.org Review URL: https://codereview.chromium.org/1884193003 Cr-Commit-Position: refs/heads/master@{#35526}
-
- 12 Apr, 2016 2 commits
-
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 Cr-Commit-Position: refs/heads/master@{#35182} Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3 Cr-Commit-Position: refs/heads/master@{#35400} Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35407}
-
machenbach authored
Revert of [compiler] Add relocatable pointer constants for wasm memory references. (patchset #15 id:320001 of https://codereview.chromium.org/1759383003/ ) Reason for revert: [Sheriff] Breaks msan: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/7842 Original issue's description: > [compiler] Add relocatable pointer constants for wasm memory references. > > Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. > > R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org > > Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 > Cr-Commit-Position: refs/heads/master@{#35182} > > Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3 > Cr-Commit-Position: refs/heads/master@{#35400} TBR=bradnelson@chromium.org,titzer@chromium.org,bmeurer@chromium.org,bradnelson@google.com,gdeepti@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1881913002 Cr-Commit-Position: refs/heads/master@{#35401}
-
- 11 Apr, 2016 1 commit
-
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 Cr-Commit-Position: refs/heads/master@{#35182} Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35400}
-
- 01 Apr, 2016 2 commits
-
-
yangguo authored
Revert of [compiler] Add relocatable pointer constants for wasm memory references. (patchset #14 id:300001 of https://codereview.chromium.org/1759383003/ ) Reason for revert: Test failures: https://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/8046 Original issue's description: > [compiler] Add relocatable pointer constants for wasm memory references. > > Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. > > R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org > > Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 > Cr-Commit-Position: refs/heads/master@{#35182} TBR=bradnelson@chromium.org,titzer@chromium.org,gdeepti@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1846083005 Cr-Commit-Position: refs/heads/master@{#35185}
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35182}
-
- 24 Feb, 2016 1 commit
-
-
bmeurer authored
These macro operators represent a conditional eager deoptimization exit without explicit branching, which greatly reduces overhead of both scheduling and register allocation, and thereby greatly reduces overall compilation time, esp. when there are a lot of eager deoptimization exits. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1721103003 Cr-Commit-Position: refs/heads/master@{#34239}
-
- 19 Feb, 2016 1 commit
-
-
bmeurer authored
This reducer doesn't really add value, because: (a) it is only concerned with JSCallFunction and JSToNumber, but when we get to it, all JSCallFunction nodes will have been replaced by Call nodes, and in the not so far future, we will also have replaced almost all JSToNumber nodes with better code, (b) and the reducer tries to be smart and use one of the outermost contexts, but that might not be beneficial always; actually it might even create longer live ranges and lead to more spilling in some cases. But most importantly, the JSContextRelaxation currently blocks inlining based on SharedFunctionInfo, because it requires the inliner to check the native context, which in turn requires JSFunction knowledge. So I'm removing this reducer for now to unblock the more important inliner changes. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1715633002 Cr-Commit-Position: refs/heads/master@{#34139}
-
- 16 Feb, 2016 1 commit
-
-
mstarzinger authored
The LazyBailout operator (modelled as a nop-call) was introduced for placing a deoptimization point into exception handlers. Now that we are no longer re-entering lazy deoptimized code, the support can be removed. R=jarin@chromium.org BUG=v8:4195 LOG=n Review URL: https://codereview.chromium.org/1697503002 Cr-Commit-Position: refs/heads/master@{#34020}
-
- 05 Jan, 2016 1 commit
-
-
sigurds authored
Deopt support is added on two levels. On the IR level, a new ObjectState node is added, which represenents an object to be materialized. ObjectState nodes appear as inputs of FrameState and StateValues nodes. On the instruction select/code-generation level, the FrameStateDescriptor class handles the nesting introduced by ObjectState, and ensures that deopt code with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are generated similarly to what crankshaft's escape analysis does. Two unittests test correctness of the IR level implementation. Correctness for instruction selection / code generation is tested by mjsunit tests. R=jarin@chromium.org,mstarzinger@chromium.org BUG=v8:4586 LOG=n Review URL: https://codereview.chromium.org/1485183002 Cr-Commit-Position: refs/heads/master@{#33115}
-
- 10 Dec, 2015 1 commit
-
-
jarin authored
MachineType is now a class with two enum fields: - MachineRepresentation - MachineSemantic Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably: - register allocator now uses just the representation. - Phi and Select nodes only refer to representations. Review URL: https://codereview.chromium.org/1513543003 Cr-Commit-Position: refs/heads/master@{#32738}
-
- 09 Dec, 2015 1 commit
-
-
bmeurer authored
This only introduces the basic support for both SOFT and EAGER deopts in TurboFan, but doesn't make use of SOFT deopts anywhere yet (there are some other issues blocking that). Basically every Deoptimize operator now has a DeoptimizeKind, which can be either kSoft or kEager. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1511883002 Cr-Commit-Position: refs/heads/master@{#32690}
-
- 03 Dec, 2015 1 commit
-
-
mstarzinger authored
This moves the proper handling for the end node withing the constructed graph into the RawMachineAssembler. This simplifies all assemblers and makes the handling of {Start} and {End} symmetrical. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1493963003 Cr-Commit-Position: refs/heads/master@{#32563}
-
- 18 Nov, 2015 2 commits
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1460583003 Cr-Commit-Position: refs/heads/master@{#32082}
-
mstarzinger authored
This ensures the class in question specifies the correct equality and hashing function when instantiated. Note that this introduces two new structs (i.e. OpEqualTo and OpHash) which can be used for defaults within OpParameter as well. R=titzer@chromium.org,bmeurer@chromium.org TEST=cctest/test-operator Review URL: https://codereview.chromium.org/1455913003 Cr-Commit-Position: refs/heads/master@{#32080}
-
- 30 Oct, 2015 1 commit
-
-
bmeurer authored
Adds new Guard[Type] common operator, which takes value and control inputs and records a guaranty that a certain value has a certain type in that control path. This is some kind of ad-hoc SSI similar to what we have to do in Crankshaft in some places. Also introduces an ObjectIsNumber simplified operator, which checks whether a certain value is a number (either a Smi or a HeapNumber). This doesn't yet support transitioning stores to double fields, which require support for allocating mutable heap numbers. R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1420283009 Cr-Commit-Position: refs/heads/master@{#31675}
-
- 19 Oct, 2015 1 commit
-
-
jarin authored
This introduces an explicit lazy bailout. It is wrapped in the call node, mostly because the lazy deoptimization processing is married to the call processing in the instruction selector and the code generator. It is still a terrible hack. R=bmeurer@chromium.org,mstarzinger@chromium.org BUG=chromium:543994,v8:4195 LOG=n Review URL: https://codereview.chromium.org/1412443003 Cr-Commit-Position: refs/heads/master@{#31353}
-
- 14 Oct, 2015 1 commit
-
-
jarin authored
This CL re-purposes ValueEffect and Finish as delimiters for regions that are scheduled atomically (renamed to BeginRegion, FinishRegion). The BeginRegion node takes and produces an effect. For the uses that do not care about the placement in the effect chain, it is ok to feed graph->start() as an effect input. The FinishRegion takes a value and an effect and produces a value and an effect. It is important that any value or effect produced inside the region is not used outside the region. The FinishRegion node is the only way to smuggle an effect and a value out. At the moment, this does not support control flow inside the region. Control flow would be hard. During scheduling we do some sanity check, but the checks are not exhaustive. Here is what we check: - the effect chain between begin and finish is linear (no splitting, single effect input and output). - any value produced is consumed by the FinishRegion node. - no control flow outputs. Review URL: https://codereview.chromium.org/1399423002 Cr-Commit-Position: refs/heads/master@{#31265}
-