This fixes PR44118. For cases where we have a chain like this:
R8 = R1 (entry value) R0 = R8 call @foo R0
the code that emits call site entries using entry values would not
follow that chain, instead emitting a call site entry with R8 as
location rather than R0. Such a case was discovered when originally
adding dbgcall-site-orr-moves.mir. This patch fixes that issue. This is
done by changing the ForwardedRegWorklist set to a map in which the
worklist registers always map to the parameter registers that they
describe.
Another thing this patch fixes is that worklist registers now can
describe more than one parameter register at a time. Such a case
occurred in dbgcall-site-interpretation.mir, resulting in a call site
entry not being emitted for one of the parameters.
I think this needs to be a MapVector. Otherwise, the iteration order in getForwardingRegsDefinedByMI will be non-deterministic. I.e. the insertion order into the Defs SmallSetVector will not be deterministic.