[Webkit-unassigned] [Bug 93080] 64-bit JSValues can be hold in an XMM register on X86

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=93080





--- Comment #5 from Yuqiang Xian <yuqiang.xian at intel.com>  2012-08-07 02:03:33 PST ---
(In reply to comment #4)
> Have you considered the following, related, optimization: if a node is known to only be used in contexts that are non-numerical, non-boolean, and the node is never used as the base of a memory access, then we can store the value of the node in an XMM register without every doing pack/unpack, and it may even be profitable to do so on 64-bit.
> 
> Example:
> 
> a: GetLocal(r42)
> b: GetLocal(r43)
> c: PutByOffset(@a, @a, @b)
> ... // no other uses of @b
> 
> In this case, @b can be stored in an XMM register since the only thing that PutByOffset is doing is storing it back to memory.
> 

Yes that can be helpful, while I guess we may need more work on the def-use analysis to detect such cases.

> This is likely to also work on any platform that has 64-bit float registers.  

That's true. This also applies to my current change. While I choose to enable it on X86 only now because it's the platform that suffers most from the lack of GPRs. I haven't yet evaluated the benefit on other platforms.

> It's likely to be most profitable if at the point of the GetLocal we are under register pressure.  But, it will require some changes to how we implement the code for things like PutByOffset - it'll have to be somehow agnostic to the source of the value being either in a GPR or in an XMM.

Agree. Even in current JIT (with this patch) we could have the code generator aware of the source of a JSValue. I choose not to do it right now as I want to keep this change simpler and haven't yet evaluated the potential benefit.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.