- 08 Oct, 2016 1 commit
-
-
mvstanton authored
And not by pointer address. BUG= Review-Url: https://codereview.chromium.org/2390823011 Cr-Commit-Position: refs/heads/master@{#40106}
-
- 06 Oct, 2016 1 commit
-
-
mvstanton authored
With this CL, we devolve all Constants introduced as they are with an object handle into * Range - for integers * Nan * MinusZero * OtherNumberConstant - for doubles * HeapConstant We reduce the amount we have to inspect an object handle during optimization. Also, simplifications result. For example, you never have to check if a Range contains a HeapConstant. BUG= Review-Url: https://codereview.chromium.org/2381523002 Cr-Commit-Position: refs/heads/master@{#40041}
-
- 27 Sep, 2016 1 commit
-
-
mvstanton authored
Adding this back in because it's not part of the stability issue. BUG=chromium:649967 TBR=jarin@chromium.org Review-Url: https://codereview.chromium.org/2365373004 Cr-Commit-Position: refs/heads/master@{#39761}
-
- 26 Sep, 2016 2 commits
-
-
mvstanton authored
Reverted for stability reasons. BUG=chromium:649967 TBR=jarin@chromium.org Review-Url: https://codereview.chromium.org/2370763002 Cr-Commit-Position: refs/heads/master@{#39720}
-
mvstanton authored
Reverted for stability reasons. BUG=chromium:649967 TBR=jarin@chromium.org Review-Url: https://codereview.chromium.org/2366313002 Cr-Commit-Position: refs/heads/master@{#39716}
-
- 23 Sep, 2016 1 commit
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2366433003 Cr-Commit-Position: refs/heads/master@{#39666}
-
- 22 Sep, 2016 1 commit
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2359153002 Cr-Commit-Position: refs/heads/master@{#39641}
-
- 05 Sep, 2016 4 commits
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2309823002 Cr-Commit-Position: refs/heads/master@{#39181}
-
bmeurer authored
We used to have Array types for typed arrays in asm.js at some point, but had to change that quite some time ago already. And Function types were mostly used for the CallInterfaceDescriptor (and the code-stub.js experiment), but are also unusedn nowadays. R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2310923002 Cr-Commit-Position: refs/heads/master@{#39168}
-
bmeurer authored
Those have been effectively unused for quite a while now, and we don't see any use in having them around. Actually it'd be way more consistent and simpler to just use OtherInternal as type for contexts instead. R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2305383002 Cr-Commit-Position: refs/heads/master@{#39166}
-
bmeurer authored
There are no users of class types left inside TurboFan, so we can nuke them and thereby simplify the type system quite a bit. R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2309753002 Cr-Commit-Position: refs/heads/master@{#39152}
-
- 01 Sep, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Many of these files we need to rebuild are cctests which pull in more includes than they need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2304553002 Cr-Commit-Position: refs/heads/master@{#39080}
-
- 17 Aug, 2016 1 commit
-
-
mstarzinger authored
This removes the representation axis from the type of {Load/StoreField} operators representing a property load/store. The representation would be narrowed to {None} which causes problems for all places where we use the type to reason about the value representation. Instead we should fully switch to {MachineRepresentation}. This is just a stop-gap fix. R=jarin@chromium.org BUG=chromium:636716 Review-Url: https://codereview.chromium.org/2255533003 Cr-Commit-Position: refs/heads/master@{#38678}
-
- 02 Feb, 2016 1 commit
-
-
jarin authored
This CL removes the Config templatization from the types. It is not necessary anymore, after the HeapTypes have been removed. The CL also changes the type hierarchy - the specific type kinds are not inner classes of the Type class and they do not inherit from Type. This is partly because it seems impossible to make this work without templates. Instead, a new TypeBase class is introduced and all the structural (i.e., non-bitset) types inherit from it. The bitset type still requires the bit-munging hack and some nasty reinterpret-casts to pretend bitsets are of type Type*. Additionally, there is now the same hack for TypeBase - all pointers to the sub-types of TypeBase are reinterpret-casted to Type*. This is to keep the type constructors in inline method definitions (although it is unclear how much that actually buys us). In future, we would like to move to a model where we encapsulate Type* into a class (or possibly use Type where we used to use Type*). This would loosen the coupling between bitset size and pointer size, and eventually we would be able to have more bits. TBR=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1655833002 Cr-Commit-Position: refs/heads/master@{#33656}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 28 Sep, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1365803004 Cr-Commit-Position: refs/heads/master@{#30963}
-
- 21 Aug, 2015 1 commit
-
-
rossberg authored
- Introduce a proper bit for SIMD primitive values. - Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type. The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter. R=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/1303863002 Cr-Commit-Position: refs/heads/master@{#30294}
-
- 10 Apr, 2015 1 commit
-
-
titzer authored
R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/1074133002 Cr-Commit-Position: refs/heads/master@{#27749}
-
- 12 Feb, 2015 1 commit
-
-
jarin authored
R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/904863002 Cr-Commit-Position: refs/heads/master@{#26621}
-
- 28 Jan, 2015 2 commits
-
-
jarin authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/882063002 Cr-Commit-Position: refs/heads/master@{#26307}
-
jarin authored
This reverts commit 76193749. BUG= Review URL: https://codereview.chromium.org/877643002 Cr-Commit-Position: refs/heads/master@{#26301}
-
- 22 Jan, 2015 1 commit
-
-
bmeurer authored
Revert of Steps towards unification of number bitset and range types. (patchset #4 id:60001 of https://codereview.chromium.org/837723006/) Reason for revert: Breaks test-types/Maybe, i.e. out/Release/cctest --random-seed=-707413401 test-types/Maybe started failing afterwards Original issue's description: > Steps towards unification of number bitset and range types. > > - New invariant on union types: if the union has a range then the number > bits in the bitset must be cleared. > > - Various tweaks in intersection and union to satisfy the invariant. > > - Exposed and used representation bits in range types (and the Limits > helper class). > > - Implemented Glb for ranges so that the Is predicate handles > ranges correctly. > > - Change typer weakening so that it does not rely on GetRange. > However, the code still seems to be a bit fragile. > > - Removed the Smi types from the type system core, instead introduced > Signed31, Unsigned30 and created constructors for Small(Un)Signed > that point to the right type for the architecture. > > - Punched a hole in the config to be able to get to the isolate so > that it is possible to allocate heap numbers for newly created > ranges. > > Patch by jarin@chromium.prg, original review here: > https://codereview.chromium.org/795713003/ > > TBR=jarin@chromium.org > BUG= > > Committed: https://crrev.com/2764fd8d1a266a9136c987c2483492113b0c8d80 > Cr-Commit-Position: refs/heads/master@{#26197} TBR=jkummerow@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/868583002 Cr-Commit-Position: refs/heads/master@{#26207}
-
- 21 Jan, 2015 1 commit
-
-
rossberg authored
- New invariant on union types: if the union has a range then the number bits in the bitset must be cleared. - Various tweaks in intersection and union to satisfy the invariant. - Exposed and used representation bits in range types (and the Limits helper class). - Implemented Glb for ranges so that the Is predicate handles ranges correctly. - Change typer weakening so that it does not rely on GetRange. However, the code still seems to be a bit fragile. - Removed the Smi types from the type system core, instead introduced Signed31, Unsigned30 and created constructors for Small(Un)Signed that point to the right type for the architecture. - Punched a hole in the config to be able to get to the isolate so that it is possible to allocate heap numbers for newly created ranges. Patch by jarin@chromium.prg, original review here: https://codereview.chromium.org/795713003/ TBR=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/837723006 Cr-Commit-Position: refs/heads/master@{#26197}
-
- 20 Dec, 2014 1 commit
-
-
machenbach authored
Revert of Remove obsolete V8_INFINITY macro. (patchset #3 id:40001 of https://codereview.chromium.org/798413003/) Reason for revert: Speculative revert. This seems to block the current roll: https://codereview.chromium.org/819653003/ I retried several times, also with a new roll. The error is internal - but that doesn't make much of a difference. Original issue's description: > Remove obsolete V8_INFINITY macro. > > Use std::numeric_limits consistently. > > R=svenpanne@chromium.org > > Committed: https://crrev.com/31c66e2d53569c4e229d55483d28208491e73612 > Cr-Commit-Position: refs/heads/master@{#25897} TBR=svenpanne@chromium.org,bmeurer@chromium.org NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/813813003 Cr-Commit-Position: refs/heads/master@{#25912}
-
- 19 Dec, 2014 1 commit
-
-
bmeurer authored
Use std::numeric_limits consistently. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/798413003 Cr-Commit-Position: refs/heads/master@{#25897}
-
- 11 Dec, 2014 1 commit
-
-
jarin authored
This reverts commit 8a6cbf0a. R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/788313002 Cr-Commit-Position: refs/heads/master@{#25786}
-
- 10 Dec, 2014 2 commits
-
-
jarin authored
Revert of Avoid number range holes in bitset types. (patchset #5 id:80001 of https://codereview.chromium.org/759013003/) Reason for revert: For breaking the waterfall (run-json-stringify test). Original issue's description: > Avoid number range holes in bitset types. > > BUG= TBR=rossberg@chromium.org NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/794663002 Cr-Commit-Position: refs/heads/master@{#25756}
-
jarin authored
BUG= Review URL: https://codereview.chromium.org/759013003 Cr-Commit-Position: refs/heads/master@{#25754}
-
- 23 Oct, 2014 1 commit
-
-
jarin@chromium.org authored
This is based on Georg's work on typing arithmetic operations (https://codereview.chromium.org/658743002/). Instead of weakening to bitset types, we weaken to the closest 2^n limit if we see that we are re-typing a node with a range type (which means that the node can be part of a cycle, so we might need to speed up the fixpoint there). BUG= R=rossberg@chromium.org Review URL: https://codereview.chromium.org/636283009 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24848 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Oct, 2014 1 commit
-
-
neis@chromium.org authored
R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/653093002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24693 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-