Add orig_insn_map: mapping from original to new insn indices.

[cfallin]

This is needed in the Cranelift client code in order to track
source-location mapping for debug info: we need to be able to shuffle
the source locations into the new locations after the regalloc has done
its instruction-stream editing. The target_map result is not quite
good enough, because it only provides old --> new mappings at a basic
block granularity.

[julian-seward1]

I see why this would be wanted. But it's another 8 bytes per instruction that the allocator needs to sit on and then drag through the machine's caches, and we're already way slow. Is this mapping needed in production runs? If not, I'd prefer to have it implemented similar to the existing request_block_annotations facility -- that is, the client passes in a flag requesting the mapping, and we return it as an Option<TypedIxVec<..>> instead. That way we can have our cake and eat it, albeit at a little more implementation complexity.

[bnjbvr]

Had a few comments below, in addition to Julian's remark.

[bnjbvr]

I suppose you maintain a mapping of new instructions to old instructions, thus needing to push None; could it also work with the inverted mapping (old instructions to new instructions), removing the need for None elements in the array?

[bjorn3]

That would make debuginfo generation slower, as you would need to iterate through the whole map to find the original instruction corresponding to the instruction you are currently emitting lineinfo for. Also you may want to attribute those extra insts to iix.

[bnjbvr]

Good point about attributing those extra insts to iix.

However i think there's still a linear way to find the source information for a given new inst, since the source locations are handled all at once: start with the first old instruction, remember what its new instruction is, then on the second instruction, you see the new inst mapping to the second instruction; you then know that all the instructions between first's new instruction and second's previous new instruction all map to the first old instruction.

[cfallin]

@bnjbvr I didn't fully grok your last sentence, but I think you're more-or-less suggesting to invert the map in one linear pass?

I actually originally had the regalloc side of this do exactly as you say, but the issue is then we have to allocate a O(|new_insns|)-sized array anyway to do the inversion, and we have the extra loop with random memory accesses to do it.

IMHO with the SourceLoc::default() value you had mentioned in the other PR, this cost (4 bytes per new-insn) is a pretty reasonable tradeoff...

[cfallin]

@julian-seward1 re: only doing this when necessary: it appears that the SourceLoc info is always needed, as shown for example by the panic caused by code we had to disable to get wasmtime to run at all. It's possible we could push the notion of "source locations are optional" further up the stack, but so far our clients seem to be built assuming it's always there.

Per @bnjbvr in the related Cranelift PR, we have SourceLoc::default() so it's actually just 4 bytes per instruction -- not ideal, but IMHO not the end of the world either, relative to our core algorithms' costs...

[cfallin]

Err, I misspoke w.r.t. the default val (we're in the regalloc crate here -- we're operating with InstIx's); perhaps we could have a "no instruction" special value in the typed index definitions to allow for this savings?

[julian-seward1]

@cfallin ah well, so be it. If we have to have it, we have to have it. I'll try and quantify the cost in the next round of RA profiling.

[cfallin]

Just added a ::not_present() option to index types (turns out there were several ad-hoc 0xFFFFFFFF not-present literals already); PTAL!

[bnjbvr]

LGTM. The fact the name not_present leaks in a few places where a default impossible value was used is a bit unfortunate, but the alternative doesn't seem much better (i.e. change vocabulary around this to "set/unset" or "defined/undefined" or "default value vs non-default", and then the regalloc.rs users may be misled by its name). Shipit!