Bug 150532 – r190735 Caused us to maybe trample the base's tag-GPR on 32-bit inline cache when the cache allocates a scratch register and then jumps to the slow path

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Saam Barati]

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

[Saam Barati]

Created attachment 264026 [details]
patch

[Geoffrey Garen]

Comment on attachment 264026 [details]
patch

r=me

[Geoffrey Garen]

...Can has regression test?

[Saam Barati]

(In reply to comment #3)
> ...Can has regression test?
Yeah. 
I was thinking I should create one.
I'll write one tomorrow before landing.

[Saam Barati]

Created attachment 264064 [details]
patch for landing

[Saam Barati]

landed in:
http://trac.webkit.org/changeset/191594