This register used to show up in the used register set because of
how the DFG kept track of used register. I changed this in my
work on online caching because we don't want to spill these registers
when we have a GetByIdFlush/PutByIdFlush and we use the used register set
as the metric of how to spill. That said, these registers should be locked
and not used as scratch registers by the scratch register allocator. The
reason is that our inline cache may fail and jump to the slow path. The slow
path then uses the base's tag register. If the inline cache used the base's tag
register as a scratch and it fails and jumps to the slow path, we have a problem.
The most obvious solution is to just make StructureStubInfo aware of the base's tag
register so that it can lock it when allocating a scratch.
Note that this doesn't mean that we can trample this register when making a call.
We can totally trample this as long as the inline cache succeeds. The problem is
only when we trample it and then jump to the slow path
Created attachment 264026 [details]
Comment on attachment 264026 [details]
...Can has regression test?
(In reply to comment #3)
> ...Can has regression test?
I was thinking I should create one.
I'll write one tomorrow before landing.
Created attachment 264064 [details]
patch for landing