1141121 - x86/x64: do not force value argument to atomic binop into a register

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Lars T Hansen [:lth]]

The register set is perfectly capable of representing the value argument as an immediate if it is a known constant, and it requires little work to fix this once the fixes for bug 1141067 are in place.

Comment 1

[Lars T Hansen [:lth]]

Another bug that's convenient to tackle at the same time is pinning the input value register to the output register when emitting XADD.

Comment 2

[Lars T Hansen [:lth]]

Attachment: Use immediates and reuse inputs when possible (x86 and x64)

Comment 3

[Hannes Verschore [:h4writer]]

Comment on attachment 8579209 [details] [diff] [review]
Use immediates and reuse inputs when possible (x86 and x64)

Review of attachment 8579209 [details] [diff] [review]:
-----------------------------------------------------------------

I'm wondering if you are potentially optimizing this too early?
Is SharedArrayBuffer already enabled / feature complete etc? It might be good to first get that fixed, before starting to optimize all these cases?

Feel free to correct me and say that is currently the most important thing to do for the future SharedArrayBuffer. I'm not quite aware of the status of SharedArrayBuffer.

Comment 4

[Lars T Hansen [:lth]]

(In reply to Hannes Verschore [:h4writer] from comment #3)
> 
> I'm wondering if you are potentially optimizing this too early?
> Is SharedArrayBuffer already enabled / feature complete etc? It might be
> good to first get that fixed, before starting to optimize all these cases?
> 
> Feel free to correct me and say that is currently the most important thing
> to do for the future SharedArrayBuffer. I'm not quite aware of the status of
> SharedArrayBuffer.

No, you're spot on.  The recent series of optimizations (this was the last of them) came about because this part of the shared memory feature is stable and because I needed to get a better grip on how to implement optimizations as a matter of course in future code.

Comment 5

[Lars T Hansen [:lth]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7cf3406ac1cd

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/7cf3406ac1cd