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] patch
Comment on attachment 264026 [details] patch r=me
...Can has regression test?
(In reply to comment #3) > ...Can has regression test? Yeah. I was thinking I should create one. I'll write one tomorrow before landing.
Created attachment 264064 [details] patch for landing
landed in: http://trac.webkit.org/changeset/191594