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}
- 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}
- Extend verifier to check types of JS and Simplified nodes.
- Untyped nodes now contain NULL as types, enforcing hard failure.
- Typer immediately installs itself as a decorator; remove explicit decorator installation.
- Decorator eagerly types all nodes that have typed inputs
(subsumes typing of constant cache, removing its typing
side-channel and various spurious dependencies on the typer).
- Cut down typer interface to prevent inconsistently typed graphs.
- Remove verification from start, since it caused too much trouble
with semi-wellformed nodes.
- Fix a couple of bugs on the way that got uncovered.
To do: verifying machine operators. Also, various conditions in the
verifier are currently commented out, because they don't yet hold.
BUG=
R=jarin@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/658543002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24626 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This requires introducing proper bounds on all leaf types, so that intersection between bitsets and these types can be accurately represented. Extending a union also becomes more involved.
(On the upside, the modified union/intersect algorithm would now allow support for proper variance for function types.)
Not sure if it is worth landing this. Distributivity isn't really a crucial property for our use cases. It seems fine if intersection is slightly lossy.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/251753005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
