This is a work-in-progress, and meant to sketch the direction I've been
thinking in for a mid-end framework. A proper BA RFC will come soon.

This PR builds a phase in the optimization pipeline that converts a CLIF
CFG into an egraph representing the function body. Each node represents
an original instruction or operator. The "skeleton" of side-effecting
instructions is retained, but non-side-effecting (pure) operators are
allowed to "float": the egraph will naturally deduplicate them during
build, and we will determine their proper place when we convert back to
a CFG representation.

The conversion from the egraph back to the CFG is done via a new
algorithm I call "scoped elaboration". The basic idea is to do a
preorder traversal of the domtree, and at each level, evaluate the
values of the eclasses called upon by the side-effect skeleton,
memoizing in an eclass-to-SSA-value map. This map is a scoped hashmap,
with scopes at each domtree level. In this way, (i) when a value is
computed in a location that dominates another instance of that value,
the first replacees the second; but (ii) we never produce "partially
dead" computations, i.e. we never hoist to a level in the domtree where
a node is not "anticipated" (always eventually computed). This exactly
matches what GVN does today. With a small tweak, it can also subsume
LICM: we need to be loop-nest-aware in our recursive eclass elaboration,
and potentially place nodes higher up the domtree (and higher up in the
scoped hashmap).

Unlike what I had been thinking in Monday's meeting, this produces CLIF
out of the egraph and then allows that to be lowered. It's overall
simpler and a better starting point (thanks @abrown for tipping me over
the edge in this). The way it produces CLIF now could be made more
efficient: it could reuse instructions already in the DFG for nodes that
are *not* duplicated (likely most of them) rather than clearing all and
repopulating.

This PR does *not* do anything to actually rewrite in the egraph. That's
the next step! I need to work out exactly how to integrate ISLE with
some sort of rewrite machinery. I have some ideas about efficient
dispatch with an "operand-tree discriminants shape analysis" on the
egraph and indexing rules by their matched shape; more to come.

…tests now.

This moves to a strategy based on `hashbrown::raw::RawTable` and
"eq-with-context" / "hash-with-context" traits, used to allow nodes to
be stored once in a `BumpVec` (which encapsulates a range in a shared
`Vec`) and then used in an eclass, with keys in the deduplication
hashtable referring to an eclass and enode index in that eclass.

This moves back to the enodes-without-IDs strategy used in `egg`, which
makes the graph rebuild simpler, but retains the single-storage /
no-cloning property.

Along the way, carrying through the eq-with-context / hash-with-context
to the `Node` itself, we can remove the `&mut [Id]` and `&mut [Type]`
slices and replace with `BumpVec`s. Actually they could be made
`NonGrowingBumpVec`s for 8 bytes instead of 12; that is future work.

This should allow equivalent algorithmic approaches to `egg` but without
the separate allocations; all allocations for nodes are now within the
entity-component-system-style large `Vec`s.

…stimated node count

…Slice` instead).

This brings the overhead of `wasmtime compile spidermonkey.wasm` with
`use_egraphs=true` and `opt_level=none` to 4.3% slower than
`opt_level=speed`. (This is an interesting comparison because the
egraph build/extract roundtrip subsumes GVN, the main time-sink in
today's opt pass.)

…parate ISLE environment.

Lots of TODOs still. The main one is how to deal with *multiple*
rewrites arising from a single rule invocation on an eclass. I think
what needs to happen is that we have multi-ctors as well as multi-etors;
these return a `SmallVec<[T; 8]>` or something of the sort. So then the
`simplify` toplevel returns a list of eclass IDs it has built that are
equivalent to the original. This means that we then need to have two
different ABIs for multi-terms: "eager" (internal multi-ctor) and "lazy"
(external multi-etor). But this is workable I think.

The egraph implementation needs much more stress-testing as well!

This is necessary to allow the `simplify` rule in the mid-end to
return multiple Ids of new e-classes that are equivalent to the
original. In general, multiplicity is a property of an extractor or
constructor (namely, a single match returns multiple results/tuples),
not just an external extractor.

…-in-egraph-extraction.

More details coming in a separate writeup!

This is more-or-less as fast as baseline Cranelift, when compared in the
following way: compiling SpiderMonkey, acyclic-egraph plus rewrite rules
(cprop and some algebraic identities) with handwritten GVN and LICM
disabled (subsumed by egraph elaboration), vs. baseline Cranelift with
those opts enabled. The egraph variant is ~1% slower.

…raph to avoid double-lookups.

…alization

…p in elaboration

…galization!

…ops via generation numbers

…ive; working on improving amode lowering.

The ISLE language's lexer previously used a very primitive
`i64::from_str_radix` call to parse integer constants, allowing values
in the range -2^63..2^63 only. Also, underscores to separate digits (as
is allwoed in Rust) were not supported. Finally, 128-bit constants were
not supported at all.

This PR addresses all issues above:
- Integer constants are internally stored as 128-bit values.
- Parsing supports either signed (-2^127..2^127) or unsigned (0..2^128)
  range. Negation works independently of that, so one can write
  `-0xffff..ffff` (128 bits wide, i.e., -(2^128-1)) to get a `1`.
- Underscores are supported to separate groups of digits, so one can
  write `0xffff_ffff`.
- A minor oversight was fixed: hex constants can start with `0X`
  (uppercase) as well as `0x`, for consistency with Rust and C.

This PR also adds a new kind of ISLE test that actually runs a driver
linked to compiled ISLE code; we previously didn't have any such tests,
but it is now quite useful to assert correct interpretation of constant
values.

…used

… node in a union

…ms to be down to 1%-ish or so again

…und remaining because some nodes cost zero points