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

RESOLVED FIXED in Firefox 39

Status

()

Core
JavaScript Engine: JIT
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: lth, Assigned: lth)

Tracking

unspecified
mozilla39
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox39 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
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.
(Assignee)

Comment 1

3 years ago
Another bug that's convenient to tackle at the same time is pinning the input value register to the output register when emitting XADD.
(Assignee)

Comment 2

3 years ago
Created attachment 8579209 [details] [diff] [review]
Use immediates and reuse inputs when possible (x86 and x64)
Attachment #8579209 - Flags: review?(hv1989)
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.
Attachment #8579209 - Flags: review?(hv1989) → review+
(Assignee)

Comment 4

3 years ago
(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.
https://hg.mozilla.org/mozilla-central/rev/7cf3406ac1cd
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.