- 07 Nov, 2016 2 commits
-
-
bmeurer authored
When we hit an unspported field store, only flush the state of potentially aliasing objects, but don't flush the full state table. R=jarin@chromium.org BUG=v8:5608 Review-Url: https://codereview.chromium.org/2476213002 Cr-Commit-Position: refs/heads/master@{#40799}
-
bmeurer authored
This adds support to track Float64 fields on 64-bit platforms, which is necessary to properly deal with unboxed double fields there. Drive-by-fix: Crash if we see Simd128 representation here. R=jarin@chromium.org BUG=v8:5608 Review-Url: https://codereview.chromium.org/2485543002 Cr-Commit-Position: refs/heads/master@{#40788}
-
- 02 Sep, 2016 2 commits
-
-
bmeurer authored
This makes it easier to read and maintain this code. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2304093002 Cr-Commit-Position: refs/heads/master@{#39127}
-
bmeurer authored
When deciding whether to nuke an element entry from the state table, base the decision for the index only on the type information, and don't even try to run it through the alias analyzer. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2301943002 Cr-Commit-Position: refs/heads/master@{#39116}
-
- 01 Sep, 2016 1 commit
-
-
bmeurer authored
For two FinishRegion nodes, the alias analysis returned "may alias" even without properly looking through them. Drive-by-fix: Add meaningful output for --trace-turbo-load-elimination. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2301903002 Cr-Commit-Position: refs/heads/master@{#39075}
-
- 31 Aug, 2016 1 commit
-
-
bmeurer authored
If the type of a tracked field or element value is less precise than the advertised type of the field or element load, then we replace the load operation with a TypeGuard that guards the advertised type. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2295643002 Cr-Commit-Position: refs/heads/master@{#39032}
-
- 26 Aug, 2016 1 commit
-
-
bmeurer authored
Using the dedicated simplified operator we are able to eliminate redundant neuterung checks as long as there is no call in the effect chain. This yields a nice speed up for the Octane Mandreel benchmark (and TypedArray-heavy workloads in general). R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2279213002 Cr-Commit-Position: refs/heads/master@{#38932}
-
- 24 Aug, 2016 1 commit
-
-
jarin authored
Unfortunately, I was unable to produce a repro without asm.js. In normal JavaScript, the bounds check renaming saves us. I have not done anything about the index variable aliasing and handling of differently sized elements yet! BUG=chromium:639210, v8:5266 Review-Url: https://codereview.chromium.org/2270793004 Cr-Commit-Position: refs/heads/master@{#38874}
-
- 16 Aug, 2016 1 commit
-
-
mvstanton authored
These new representations aren't used yet. BUG= Review-Url: https://codereview.chromium.org/2216383002 Cr-Commit-Position: refs/heads/master@{#38657}
-
- 12 Aug, 2016 1 commit
-
-
bmeurer authored
A TransitionElementsKind operation is redundant if we already know that the object has the target_map (independent of what the source_map might be). R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2233403003 Cr-Commit-Position: refs/heads/master@{#38597}
-
- 11 Aug, 2016 1 commit
-
-
bmeurer authored
If the intersection of the types of nodes a and b is empty, then there's no way that a and b could ever refer to the same object, so we can use that information for alias analysis. Drive-by-fix: Improve use of types to enable typed alias analysis to become more effective. Also fix an ASAN issue uncovered by this CL. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2237433003 Cr-Commit-Position: refs/heads/master@{#38567}
-
- 08 Aug, 2016 1 commit
-
-
bmeurer authored
Introduce a dedicated MaybeGrowFastElements simplified operator, which tries to grow a fast elements backing store for a given element that should be added to an array/object. Use that to lower a growing keyed store to a sequence of 1) check index is a valid array index, 2) check stored value, 3) maybe grow elements backing store (and deoptimize if it would normalize), and 4) store the actual element. The actual growing is done by two dedicated GrowFastDoubleElements and GrowFastSmiOrObjectElements builtins, which are very similar to the GrowArrayElementsStub that is used by Crankshaft. Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements builtin, similar to the new growing builtins, so we don't need to inline the store+write barrier for the elements into all optimized code objects anymore. Also fix a bug in the OperationTyper for NumberSilenceNaN, which was triggered by this change. BUG=v8:5272 Review-Url: https://codereview.chromium.org/2227493002 Cr-Commit-Position: refs/heads/master@{#38418}
-
- 05 Aug, 2016 3 commits
-
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 Review-Url: https://codereview.chromium.org/2218703003 Cr-Original-Commit-Position: refs/heads/master@{#38370} Cr-Commit-Position: refs/heads/master@{#38392}
-
bmeurer authored
Revert of [turbofan] Add support for copy-on-write element stores. (patchset #2 id:20001 of https://codereview.chromium.org/2218703003/ ) Reason for revert: Breaks tree? Original issue's description: > [turbofan] Add support for copy-on-write element stores. > > This extends JSNativeContextSpecialization with support for stores to > fast object/smi element backing stores that are marked as copy-on-write. > In this case we first call the CopyFixedArray builtin to take a copy of > the elements backing store, and then store the new elements back to the > object, and finally perform the actual element store. > > R=epertoso@chromium.org > BUG=v8:4470 > > Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 > Cr-Commit-Position: refs/heads/master@{#38370} TBR=epertoso@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470 Review-Url: https://codereview.chromium.org/2220513002 Cr-Commit-Position: refs/heads/master@{#38376}
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2218703003 Cr-Commit-Position: refs/heads/master@{#38370}
-
- 02 Aug, 2016 1 commit
-
-
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}
-
- 29 Jul, 2016 1 commit
-
-
bmeurer authored
So far we always create explicit control flow for map checks during JSNativeContextSpecialization, or in the monomorphic case we used a CheckIf combined with a map comparison. In either case we cannot currently effectively utilize the map check information during load elimination to optimize (polymorphic) map checks and elements kind transitions. With the introduction of CheckMaps, we can now start optimizing map checks in a more effective fashion. This CL doesn't change anything in that direction yet, but merely changes the fundamental mechanism. This also removes the stable map optimization from the Typer, where it was always a bit odd, and puts it into the typed lowering and the native context specialization instead. R=epertoso@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2196653002 Cr-Commit-Position: refs/heads/master@{#38166}
-
- 28 Jul, 2016 1 commit
-
-
bmeurer authored
Split the monster methods in JSNativeContextSpecialization into smaller ones, adding appropriate helpers. Improve the condition checking for strings and numbers using CheckString/CheckNumber when applicable. Also try to merge compatible PropertyAccessInfos, to avoid running into the polymorphic case whenever possible. Drive-by-fix: Don't try to resurrect dead nodes during LoadElimination. With the improve code generation for monomorphic loads, we seem to trigger the dead node resurrection. R=epertoso@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2191823002 Cr-Commit-Position: refs/heads/master@{#38127}
-
- 25 Jul, 2016 1 commit
-
-
bmeurer authored
Turn the LoadElimination into a proper graph Reducer so that it can run together with ValueNumbering and RedundancyElimination to a fixpoint for maximum load/check elimination. This also adds initial support for eliminating redundant LoadElement/StoreElement nodes. BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2164253002 Cr-Commit-Position: refs/heads/master@{#38015}
-
- 05 Jul, 2016 1 commit
-
-
bmeurer authored
This adds a new optimization phase to the TurboFan pipeline, which walks over the effect chain and tries to eliminate redundant loads (and even some stores) of object fields. We currently ignore element access, but that will probably need to be handled as well at some point. We also don't have any special treatment to properly track object maps, which is also on the list of things that will happen afterwards. The implementation is pretty simple currently, and probably way to inefficient. It's meant to be a proof-of-concept to iterate on. R=jarin@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2120253002 Cr-Commit-Position: refs/heads/master@{#37528}
-
- 30 Jun, 2016 1 commit
-
-
jarin authored
Revert of [compiler] Load elimination now traverses CheckTaggedPointer. (patchset #1 id:1 of https://codereview.chromium.org/2104893002/ ) Reason for revert: Clusterfuzz breakage (https://bugs.chromium.org/p/chromium/issues/detail?id=624756) Original issue's description: > [compiler] Load elimination now traverses CheckTaggedPointer. > > It also dereferences the inputs of StoreField, if those were > CheckTaggedPointers. Tested manually. > > BUG= > > Committed: https://crrev.com/f416886358c0aeaa5b4d1e83d9c7d6bb8b0e7f2f > Cr-Commit-Position: refs/heads/master@{#37330} TBR=bmeurer@chromium.org,bgeron@google.com # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review-Url: https://codereview.chromium.org/2113623002 Cr-Commit-Position: refs/heads/master@{#37438}
-
- 29 Jun, 2016 1 commit
-
-
bmeurer authored
The only real use case left for TypeGuard was the renaming inside the LoadElimination, but this case only occurs in dead code (guarded by a previous Check), so it's not relevant, and we can drop the TypeGuard operator completely. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2108793003 Cr-Commit-Position: refs/heads/master@{#37361}
-
- 28 Jun, 2016 1 commit
-
-
bgeron authored
It also dereferences the inputs of StoreField, if those were CheckTaggedPointers. Tested manually. BUG= Review-Url: https://codereview.chromium.org/2104893002 Cr-Commit-Position: refs/heads/master@{#37330}
-
- 18 May, 2016 1 commit
-
-
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}
-
- 02 May, 2016 1 commit
-
-
bmeurer authored
For LoadElimination we must not replace LoadField nodes with other nodes whose types are not a subtype of the original LoadField type, as that breaks the verifier. We already fixed that earlier for store to load forwarding, but the fix didn't cover LoadField forwarding. This actually still generates the correct code even w/o the fix, but since recently fails due to stronger checking in representation selection. So this makes clusterfuzz happy again. R=mvstanton@chromium.org BUG=chromium:607899 LOG=n Review-Url: https://codereview.chromium.org/1934973002 Cr-Commit-Position: refs/heads/master@{#35930}
-
- 05 Apr, 2016 1 commit
-
-
jarin authored
In simplified numbering, we make sanity checks based on types (e.g., NumberSubtract should take numbers as inputs), but this can be violated if optimization passes make types less precise. In this CL, we fix load elimination to make sure that types are smaller in the store -> load elimination by taking an intersection of the load's type with the store value's type and inserting a guard with that type. Note that the load type comes from type feedback, so it can be disjoint from the stored value type (in that case, this must be dead code because the map chack for the load should prevent us from using the stored value). BUG=chromium:599412 LOG=n Review URL: https://codereview.chromium.org/1857133003 Cr-Commit-Position: refs/heads/master@{#35259}
-
- 23 Nov, 2015 1 commit
-
-
bmeurer authored
The LoadElimination in TurboFan can look into the atomic regions and elimination subsequent loads based on stores/allocations in that atomic regions. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1472703005 Cr-Commit-Position: refs/heads/master@{#32179}
-
- 05 Jun, 2015 1 commit
-
-
mstarzinger authored
This in turn allows usage of AdvancedReducer::ReplaceWithValue which has access to the underlying graph reducer. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1158723005 Cr-Commit-Position: refs/heads/master@{#28817}
-
- 29 Jan, 2015 1 commit
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/883613006 Cr-Commit-Position: refs/heads/master@{#26316}
-
- 05 Dec, 2014 1 commit
-
-
Benedikt Meurer authored
This is an initial version of redundant load elimination, currently limited to LoadField operators, and implemented by walking the effect chain. TEST=unittests R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/782473002 Cr-Commit-Position: refs/heads/master@{#25673}
-