Wasm baseline: Avoid SNaN -> QNaN conversion for constant arguments to Min and Max

REOPENED
Unassigned

Status

()

Core
JavaScript Engine: JIT
P5
normal
REOPENED
2 years ago
2 months ago

People

(Reporter: lth, Unassigned, Mentored)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

In emit{Min,Max}F{32,64}() we unconditionally convert arguments from signaling NaN to quiet NaN by adding 0.0.

It is silly to do this for constant values, so we should definitely avoid that, and that is especially true since Min and Max often will be applied to one constant argument.

It is interesting to consider whether there is a simple way to know that a value cannot be a signaling NaN.  For example, off the top of my head I would say that the result of an arithmetic operation can't be signaling.

It does not look like it's worthwhile to go down the more complex path here, since the fixup is relatively cheap (clear a register and subtract, and we hope the FPU optimizes that path.)  Still, worth remembering.
(Reporter)

Updated

2 years ago
Mentor: lhansen
Created attachment 8827578 [details] [diff] [review]
bug1316824-avoid-redundant-snan-conversion.patch

Something like this, but for the other three cases as well, and with test cases.
Micro-optimizations in straight-line code without emipirical support are P5.
Priority: P3 → P5

Comment 3

2 months ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
You need to log in before you can comment on or make changes to this bug.