search

bytecodealliance / regalloc2

A new register allocator
Apache License 2.0
209 stars 38 forks source link

Replace manual use of index newtypes `bundles[bundle.index()]` with `Index` impls and typed `Vec` wrappers #62

Open cfallin opened 2 years ago

cfallin commented 2 years ago

Right now, regalloc2 uses an entity-component-system sort of pattern with toplevel Vecs of LiveBundle, VRegData, and the like, and newtype'd index wrappers like LiveBundleIndex, VRegIndex, etc. We have a whole bunch of instances of self.bundles[bundle.index()]....

Ideally we would make bundles a Vec-wrapper type that has an Index implementation that natively takes LiveBundleIndex, and then we could make all of these sites slightly less verbose.

Amanieu commented 2 years ago

Could we just use cranelift-entity for this?

bjorn3 commented 2 years ago

That would likely require moving cranelift-entity out of the wasmtime repo and independently versioning it. Otherwise you are pretty much stuck with two copies in case you are compiling cranelift.

cfallin commented 2 years ago

Yeah I'd be hesitant to introduce a circular dependency in general between repositories. (Perhaps cranelift-entity really should be its own little independent library, but that's a slightly bigger question...)

fitzgen commented 2 years ago

Or regalloc2 should be under cranelift/ in the Wasmtime repo.

cfallin commented 2 years ago

That's a much bigger discussion as well... at the time at least, we had good reasons to not do that: different (lighter-weight) CI here, historical precedent wrt regalloc.rs, general modularity (I would argue by default separable libraries should be separate, and the burden of argument is on the consolidation side, but that's of course subjective...). I'm not completely opposed to it now but that's a big thing to re-consider especially now that it's established, others have forked and contributed, may have direct references to it. Basically subsuming the whole repo into another one feels out of proportion to the upside "can use a nice indexing type". (Of course if anyone feels strongly about this they're welcome to create a toplevel issue for it!)

Amanieu commented 2 years ago

That would likely require moving cranelift-entity out of the wasmtime repo and independently versioning it. Otherwise you are pretty much stuck with two copies in case you are compiling cranelift.

Is this resolved by the upcoming Wasmtime 1.0 release?

FWIW I'm already using cranelift-entity outside of Cranelift, for my own compiler.

bjorn3 commented 2 years ago

If regalloc2 were to use cranelift-entity as is, you would get two copies of cranelift-entity. One used by regalloc2 from crates.io and one used by cranelift part of this repo.

Amanieu commented 2 years ago

Not if cranelift-entity was 1.0, since the 2 uses would be semver-compatible and Cargo would satisfy both of them with a single dependency version.

bjorn3 commented 2 years ago

I don't think that works when one of the versions is from crates.io and the other is a path dependency.

cfallin commented 2 years ago

The switch to 1.0-series versions (bumping major number at each release) don't change anything here, I think; the plan is still for each release to be a semver bump wrt the last one.